On Sunday 21 October 2007, Michael Halcrow wrote: > 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? >
<snip> > factor at this point. Well, there is an historical factor too. Right. This is the truth. I understood that initially it sounded good when you had passphrase only implementation. > 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 Oh... I thought linux is going into micro-kernel approach, moving components to userspace when possible. Even if you have RSA in kernel, remember our long discussion regarding PKCS#11 implementation, you and Kent insisted to perform the public key operation via the SAME module that provides the private key operation. I don't know if we finally agreed to call public key operation hardware "ACCELERATOR", but if you use RSA in kernel, you force people to write such accelerators in kernel mode... This results of moving more code into the kernel, and I hope will be rejected. Having private key operations in kernel is just a bad idea, as you cannot protect the private key (unless you actually do PKCS#11 or related calls), but then why not implementing programs in kernel mode as well? :) > 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. Sure it is required. You wanted to do private key operations. Private keys by definition should not be available for extraction. So you must have some means in order to access them. The daemon/netlink were good decisions, I don't understand why you don't like 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. I don't understand how it works with OpenSSL key module... You can load the keys but they are unusable. So pam may load something in unsecured memory, but it the home directory is unaccessible anyway. > 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 the kernel keyring is not the issue we discuss. The issue we discuss is user mode interaction between processes. Let's agree first you must have a daemon for private key operations. If we agree we have to communicate securely between two userspace processes. This had been solved many times in the same manner. > 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 don't understand how access control may be impose here. As if one userspace process needs write access, and other userspace daemon needs read access and we don't want a daemon per key (session), the only ACL may be process name based which are the worse ACLs you can find out there. Daemon per key not good for hardware related operations as you lose hardware session between daemons, prompting for passphrase more than you should. Also, people may think it is not proper to store in memory the passphrase of their keys (RSA and PKCS#11), so you need to handle this issue as well. So, for example, the pam will acquire credentails, forward it to the daemon for one time use, you don't store the passphrase. > 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. I don't think SE Linux provide a solution anyway.... > 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. "write-only" but can be "read-only" by the dameon :) > 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. Do you know processes holding your user's password even if they don't use it? This is the same of not using Kerberos as authentication framework, and just re-type the user's password over and over. > - 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. I don't understand. How do you wish to access hardware this way? Without hardware you have no security. > - 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. This is fine. But you don't get your acceleration you requested in the past. > - 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. This will not be possible in secured implementation. You are right, storing all the passphrase private key etc in memory (keyring) is the simplest solution, but it will not be the secured one. > 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. Well... I raised this issue only to help, I was quite surprised. This is the first "security aware" project I know that holds secrets readable in memory. I really don't understand why you don't like the daemon. I think you should embrace it, delegating as much functionality into it. This is the only way to have secured platform. ssh-agent and gpg-agent are the model I think easily solves all the issues. That's true that part of the implementation is in kernel space, but the implementation is no different from other userspace only implementations (that's why I asked regarding the fuse). Best Regards, Alon Bar-Lev. ------------------------------------------------------------------------- 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
