(adding David Howells and Serge Hallyn to the cc: list because this deals with the proper use of the keyring and SELinux in protecting keys)
On Mon, Oct 15, 2007 at 07:23:53PM +0200, Alon Bar-Lev wrote: > Hello, > > SELinux is not a solution. SELinux can apply types to eCryptfs-related keys in the keyring, and then individual applications can be constrained according to the domains that should have access to eCryptfs-related keys. This provides a way to limit access to keys to a more granular level than that of the uid, and it really is quite straightforward. > What policy had you considered? That only /usr/bin/ecryptd can > access key contents? Any userspace application that would like to manipulate eCryptfs keys can be labeled to be in the requisite domain. ecryptfsd may never be in the picture at all; for instance, when it comes to passphrase-only mode of operation. In that case, /sbin/mount.ecryptfs and /usr/bin/ecryptfs-manager will need to be able to manipulate the eCryptfs keys, without any daemon running. Or, any other key management utilities that the user may choose to run to help him manage his eCryptfs keys. > What if there are some other applications using this interface? You > need some convention for the key name... Something like > ecryptfs.<hash>, so that you affect only your keys. You are correct that there is a namespace issue. I would really like there to be something like an "ecryptfs" keyring for eCryptfs-specific key objects. This should not be too difficult to implement. Then, we can link that keyring into individual process keyrings. I will have to think through this a bit more. > And of course, what about users who don't use SELinux? At their > system any process can get key contents. Any of *their* processes can get the key contents. In other words, the *user* can read *his own* keys. Why is this a problem? What is the threat model you have in mind? If a user cannot trust his own processes... well, let's just say that he has much bigger problems to deal with at that point. If any given key module wants to protect secret information, it can do so by loading a handle to secret data into the key object, using that handle to get to its secret data (as is the case with the TSPI key module). > The kernel module does not really need the keys anyway... ...for asymmetric key operations. But eCryptfs has a symmetric passphrase mode too. eCryptfs needs the keys if any eCryptfs subsystem winds up doing something similar to what the passphrase mode of operation does. At some point, I would like to implement a notion of "key groups" that are dominated by individual symmetric "master" keys in order to improve performace. Calls out to ecryptfsd would only need to be made once per key group. These keys need to be managed by the user, via any mechanism the user desires to use. > So using this interface in order to pass keys between > ecryptfs-manager and ecryptfsd is somewhat not needed and exposes > sensitive information, it is just like keeping the contents of the > keys in files... Except the keyring contents are not written out to secondary storage media. > I think the ecryptfs-manager and ecryptfsd should communicate as any > usermode applications do, via pipe, in a way sensitive information > cannot be extracted from ecryptfsd. ecryptfsd is a strictly optional component of the entire eCryptfs system. ecryptfsd needs to be able to die and be restarted arbitrarily, and active eCryptfs mounts must continue to perform operations that have no need of the daemon. Any given instance of ecryptfsd is entirely irrelevant; anything at all that a key module will ever need to do its job correctly will be in the serialized key object itself (or, at least *referenced* by the key object; the key module can figure out where to go and how to get the key from that reference). This implies that ecryptfsd could even be running *on another host*, and a TLS-protected socket to the daemon on the other host should be able to process the key packet requests. This is one of the reasons why messaging.c in the eCryptfs kernel code base is generic and makes reference to other transports other than netlink. Furthermore, new keys should be able to be loaded by any of the user's applications into the user's keyring during an active eCryptfs mount, and the eCryptfs kernel module should be able to use those keys to open any existing files on disk. I do not want to introduce extra dependencies on the userspace daemon unless such dependencies are absolutely necessary in order to meet security requirements. Thanks, Mike > The kernel module should enumerate available keys' hash via netlink > interface so it knows if the default key is loaded into the daemon. > > This solution is simple, and can be implemented with SELinux and > without. > > And whatever solution is used, it just makes the interactive user > interaction even more important... > > Best Regards, > Alon Bar-Lev. > > On 10/15/07, Michael Halcrow <[EMAIL PROTECTED]> wrote: > > On Mon, Oct 15, 2007 at 07:24:11AM +0200, Alon Bar-Lev wrote: > > > This key was created using ecryptfs-manager... And I can read the > > > contents of it, as any other usermode application. So my conclusion > > > is that it is unsecured. > > > > The kernel user session keyring restricts access to the granularity of > > the uid. If you want more granular access control over the keyring > > contents, I recommend using SE Linux to induce labeling on the keyring > > objects to restrict access to whatever roles you want: > > > > http://lwn.net/Articles/186082/ > > > > > Maybe ecryptfs-manager does not use the key interface correctly, and > > > it should set the permission of the key so that it cannot be viewed > > > by the user, having the cryptfs kernel mode extract the contents and > > > send it via the netlink socket? > > > > eCryptfs is architected so that the user can freely manipulate his own > > keys using any processes he so desires. The general idea is that if > > the user's own processes can't be trusted, then the user is pretty > > much screwed anyway. Unless, of course, you are running a MAC system, > > like SE Linux. > > > > One request that recently came up is to distribute a sensible SE Linux > > policy for eCryptfs in Fedora 8. > > > > Mike > > > >
pgphSGsUfEwQJ.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ eCryptfs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
