On 10/15/07, Michael Halcrow <[EMAIL PROTECTED]> wrote: > (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)
I will not discuss SELinux, as it is one solution and as most users don't use it, or don't configure it correctly it is irrelevant for basic configuration. I think the openssh and gnupg should be a base for design, SELinux can only improve the security level. > On Mon, Oct 15, 2007 at 07:23:53PM +0200, Alon Bar-Lev wrote: > > 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. But the user cannot select specific SELinux configuration, you set this system wide... So actually you have to use fixed binaries that can access your keys. But again... SELinux is not the issue. > > 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. Something like this must be implemented in order to run several applications with different policies. > > 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). Users enters their password within one application do not expect other application to be able to get this password... Basic and simple expectation. The fact you trust application A, does not mean you trust application B. Most applications follow this rule, eCryptfs is a major exception. So, for example, if you enter your password to ssh, you don't expect other application may retrieve it. If you enter a password for login process you don't expect it will be exposed so other process may login at later time on your behalf. This has nothing to do with TSPI... As you need passphrase to access TSPI, right? And what do you do with this passphrase? Having a security credentials without "something you know" somewhat make the whole idea redundant. > > The kernel module does not really need the keys anyway... > > ...for asymmetric key operations. But eCryptfs has a symmetric > passphrase mode too. Well... OK... User who wish low level of security may not use the daemon and load their passphrase into the public key store.... But what happens if the user do wish to have some security (AND NOT USE SELINUX)? I would expect he will be able to load the passphrase into the daemon, at least it will not be extracted from there. > 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. I don't understand how this is related... As if the daemon is used and it is the only one who have access to the key, it is fine. > > 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. You can also allocate this kind of memory in userspace. > > 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. I understand what you want to accomplish, but I think it will be the "unsecured configuration", suggested configuration would be using the daemon, so credentials will not leak. Alternatively, a daemonless passphrase only mode can import keys into the key store without permission for the user to get their contents. > ecryptfsd needs to be able to die and be restarted > arbitrarily, I don't see how this is related, as if it dies and restarted it will reread keys (manual or automatic), and it will work... (As it does now). > and active eCryptfs mounts must continue to perform > operations that have no need of the daemon. Again... I don't see how it is related, as after the daemon provide the encryption key, ecryptfs can continue working without the dameon, as it does now. > 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). I don't understand... If you mean getting it interactively - that's OK, but if not... we have egg and chicken situation here. > 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. Hmmmm.... I thought Linux is going in micro kernel approach, removing unnecessary logic from kernel into user, if you ever want to do TLS, I hope you leave the daemon on local machine, and implement the tunneling via usermode to usermode. > 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. I don't see how this is a problem, you add new keys to the daemon exactly as you do with ssh-add, keys that are added to the daemon will be available to the kernel module. In short... the key interface is a good interface only if you add key material without permission to extract the data, then kernel mode may use this key safely. But if you wish user mode to read the key material using this interface only exposes sensitive information, so a better solution is required. 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
