Hello, SELinux is not a solution.
What policy had you considered? That only /usr/bin/ecryptd can access key contents? 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. And of course, what about users who don't use SELinux? At their system any process can get key contents. The kernel module does not really need the keys anyway... 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... 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. 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 > > ------------------------------------------------------------------------- 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
