[00:29:31] --- Russ has left: Disconnected [01:21:11] --- dev-zero@jabber.org has left: Replaced by new connection [01:21:12] --- dev-zero@jabber.org has become available [03:52:17] --- haba has become available [06:48:13] --- jaltman has left: Disconnected [09:29:47] --- dev-zero@jabber.org has left [10:07:14] --- Russ has become available [11:47:04] --- dev-zero@jabber.org has become available [11:57:37] --- dev-zero@jabber.org has left [11:57:50] --- dev-zero@jabber.org has become available [12:13:26] --- dev-zero@jabber.org has left [12:13:36] --- dev-zero@jabber.org has become available [12:23:16] --- dev-zero@jabber.org has left [12:23:41] --- dev-zero@jabber.org has become available [13:01:39] --- dev-zero@jabber.org has left [13:02:11] --- dev-zero@jabber.org has become available [13:09:27] --- haba has left [13:36:47] --- dev-zero@jabber.org has left [13:37:01] --- dev-zero@jabber.org has become available [14:29:15] --- jaltman has become available [14:31:13] not only are the pioctl numbers different but the data structures are as well [14:32:14] I was going to steal the Windows number for flushall, but I'll just grab my own when I get round to it again ... [14:34:31] --- dev-zero@jabber.org has left [14:34:32] flushall invalidates all of the data. it doesn't actually erase the contents. is there any reason to add a "fs flushall -purge" option that would memset the data buffers? [14:34:48] In the long run, I think there might be. [14:35:12] Unix has much the same problem with flushvolumes - it marks the data as invalid, but doesn't actually delete any of it. [14:35:32] You've probably got a bit less of a problem, as your cache isn't nicely stored as files on the local disk. [14:36:14] my problem might be worse as the single file is easier to move [14:36:47] It depends on your threat, I guess. [14:37:19] The situation we're terrified about here is the "lost laptop" scenario, where someone leaves a laptop somewhere and confidential data is trivially recoverable. [14:38:45] Anything targetted - so someone actively setting out to steal the laptop, or even being aware of how to retrieve data that is obfuscated, is seen as less of a concern. [14:40:16] adding a kill cache RPC from a file server or vldb server would be trivial for the Windows CM [14:41:37] I should add a registry key to force the use of an encrypted cache file [14:49:23] You'd want a secure callback channel before you permitted a kill cache RPC, I think. [14:49:51] The big issue is what happens with open files when the cache gets killed... [14:50:26] same behavior as InitCallback3 [14:50:50] it just erases the contents of the buffers in addition to clearing the callback flags [14:50:55] Not on Unix. [14:51:08] If you've got an open file, you get to keep your data until you close(). [14:51:36] (why should you lose your edits just because the fileserver went out to lunch?) [14:51:49] Unix should be clearing the callback [14:52:50] It clears the callback. But a callback break has no effect on a file which is dirty. [14:53:01] I agree that an authenticated channel is preferred. Unix has a different issue as well. It doesn't preserve the UUID of the CM from session to session. There is no way to track it [14:53:54] That's not an issue currently, because there's no state on Unix that we care about that persists from session to session. [14:54:23] isn't the cache data preserved? [14:54:35] Yes, but not in a way that you can get access to it. [14:54:49] All callbacks go, everything's marked as invalid when the machine comes back up. [14:55:23] sure. same on Windows. [14:55:33] Disconnected will change that a little of course. [14:55:46] but the buffers are marked with FID, offset, and data version [14:56:09] Yeh, so as soon as you do a FetchStatus and the dv matches, you get your data back. [14:56:50] But I'm not sure how tracking UUID will help us here. I don't think the solution to Russ's problem is for the server to be able to delete data from a client, even if it's been rebooted. The delivery issues are too great. [14:57:30] What you really want is a way of adding an advisory flag to the data when you send it that specifies some kind of a limited life, or caching policy, for the data. [14:57:38] Russ' use model is different. the cache manager can only access the servers either while in a particular lab or via a VPN [14:58:10] he needs a method that says "if the file servers are not accessible, then blow the data away" [14:59:38] Yeh, and a way of signalling that that applies to that data. Either a volume flag, or something similar. [15:04:40] --- dev-zero@jabber.org has become available [15:09:45] I'm okay with being able to set a timeout on the data, although yeah, ideally we want to blow it away when the network changes away from the VPN. We're in the same boat as Simon: the case that everyone is worried about is a lost laptop with trivially-recoverable data, so anything in the AFS cache is probably already obfuscated enough. [15:09:56] But it would be nice to have some clear way to blow it away. [15:10:19] Stop the cache manager, rm -rf CacheItems, restart the cache manager :) [15:11:00] Or fs flushall, which I can write for you just as soon as I've extracted my head from how rxgk secures the callback channel... [15:15:36] --- dev-zero@jabber.org has left [15:15:48] --- dev-zero@jabber.org has become available [15:21:00] I'm beginning to think that if we want to secure the callback channel, we need to have some kind of strong binding between a cache manager's key material, and its UUID. [15:24:39] the cache manager UUID or the file server UUID? [15:24:47] cache manager UUID. [15:25:42] The problem, essentially is that callbacks are currently all sent based on the UUID, and yet our security model is based around a GSSAPI identity. If you don't have a strong binding there, then an attacker can register your UUID with a bogus identity. [15:25:54] (Bearing in mind that client identities can be anonymous) [15:29:27] Actually, I think I may have a solution. It just means that the fileserver has to track each callback it issues as to whether it can be broken/updated securely or not. [15:33:41] A UUID is global to the cache manager in that one value is used for all cells. I think if we wanted to have secure UUIDs that we would need to have a separate UUID for each cell. [15:34:04] I think we can work round this. Here's my thinking ... [15:34:28] For a callback to be secure, you want to make sure that the endpoint receiving the callback is the one that performed the RPC in the first place. [15:34:48] The key to that is using the cache manager identity (not the user identity). [15:35:45] So, you permit a cache manager to set a key for the callback channel via an RPC to the fileserver. If a key already exists for that UUID, and the identity differs from the one that set that key, then you have to break all existing callbacks before setting the new key. [15:36:06] there are two things the client wants to know. It wants to know that the call is meant for it and that the source was the file server that it obtained the callback from. [15:36:40] Whenever you process an RPC that sets a callback, you have to check that the identity performing that RPC contains the client identity you currently have stored for that CM. If it differs, you can't do a secure callback, and you fall back to an insecure one. [15:38:08] I think those cover all of the attack scenarios I can think of. In particular, I'm worried about the situation where an attacker replaces a legitimate client in order to obtain information contained in extended callback breaks. [15:39:05] the secure callbacks should be encrypted [15:39:26] if the RPC that established the callback was encrypted [15:39:46] That's irrelevant if an attacker can cause their own key to be used for that encryption - but yes. [15:40:14] the key needs to be established before the RPC can be issued [15:40:43] Which key? [15:42:09] the key established for the callback channel [15:42:53] So there's two things you have to protect against there. The first is an attacker having set the callback channel key to something of their own choosing before you do the RPC. [15:43:13] The second is an attacker changing the callback channel key after you've performed the RPC, but before you get the results. [15:43:21] I think both are handled in what i outlined. [15:50:14] --- dev-zero@jabber.org has left [15:50:29] --- dev-zero@jabber.org has become available [16:07:58] --- dev-zero@jabber.org has left [16:08:10] --- dev-zero@jabber.org has become available [17:57:17] --- jaltman has left: Disconnected [21:11:05] --- jaltman has become available [22:25:57] --- dev-zero@jabber.org has left [23:21:08] --- Russ has left: Disconnected