On Sun, Oct 21, 2007 at 12:00:20AM +0200, Alon Bar-Lev wrote: > Except for the passphrase keys which are used directly by the kernel > module, why should the other keys modules use the key store anyway?
By keeping the keys in the user's persistent in-memory keyring, keys and daemon instances are entirely independent of each other. Daemons can be killed and restarted without having to go through another round of key initialization, various user applications can add and/or use the keys for their own purposes, etc. It's purely a convenience factor at this point. Well, there is an historical factor too. > I think that any key not known to the kernel can be forward (as > default route) to the netlink socket for further processing. Also > the default encryption key if not exists on store (none passphrase), > it may be forwarded to the netlink socket. The keyring was used as the common means of getting keys between kernel and userspace before the daemon and netlink socket ever existed. If RSA code ever makes it into the kernel (i.e., the MPI patchset), then some public key operations can be implemented entirely in the kernel module too. http://www.uwsg.indiana.edu/hypermail/linux/kernel/0703.2/1037.html I have said it before and I will say it again: I want to avoid introducing any dependencies on the userspace daemon that are not absolutely necessary at the moment. Frankly, I am not at all crazy about having to defer to a userspace daemon *in the middle of a syscall* anyway, and I would love to find ways to get rid of that step wherever possible. Adding dependencies on userspace components is exactly opposite of the direction I want to see eCryptfs go. The userspace components are there today only because some key management tasks absolutely require them. The kernel keyring service is simply an obvious place for *any* user application to be able to make keys available for the eCryptfs kernel module to consume later, independent of any daemon, wherever humanly possible. This allows pam_ecryptfs.so, for instance, to get the key available without having to launch a special daemon process in the middle of the user login. If the kernel keyring cannot securely provide this service, than I would start asking how to extend the kernel keyring to do that job before I would want to consider abandoning it altogether. But I really sense that your concerns relate directly to the level of *access control* that can be asserted over the secret values, regardless of the mechanism used to handle them. I agree that making the keys readable by *any* of the user's processes may be undesirable, and I understand your point about the complexity of requiring users to write SE Linux policies to use domain and type enforcement for more fine-grained access control. Outside of SE Linux policies, is there a way to make a "write-only" keyring, that only the eCryptfs kernel module or the userspace daemon can read the keys provided? I would prefer to only require key management apps to have to use the standard kernel keyring API to make those keys available. The model that I want to eventually achieve is this: - *Any* application can make new keys available to the eCryptfs kernel module *at any time* by only using the standard kernel keyring API. Even when there is no daemon running. - A single key object in the keyring can be used by OpenSSL, GnuPG, eCryptfs, or whatever. This is my fantasyland idea, where all crypto apps agree to use a single well-protected central point-of-access to get secret values for the life of the user's session. SE Linux can be used to achieve something like this right now, but perhaps the kernel keyring can be made to allow some kind of ACL to govern access to keys in the session keyring. - Callouts to the userspace daemon are only done for operations that absolutely require userspace components to complete. RSA is in the kernel, so standard boring public key operations are done without blasting messages out to a userspace daemon in the middle of syscalls. - Daemon instances are totally irrelevant; the user can kill his own ecryptfsd and restart it at will, and existing eCryptfs mounts will continue to operate exactly as expected, without -EIO errors suddenly being returned to other apps, and without having to go through special extra key-initialization steps. Whatever gets us closer to that model is what I tend to prefer. I am less inclined to adopt changes that take us farther from that model. Thanks, Mike
signature.asc
Description: Digital 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
