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
pgpCjmHCj0oq0.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
