On 8/19/05, Hans Reiser <[EMAIL PROTECTED]> wrote: > I think it would make sense to put the keys as files in /proc: > e.g. > touch /proc/1/keys/private/"0893410984328098094321" > would give init (aka process with id of 1) a new key that its children > would not inherit > touch /proc/1/keys/inheritable/"1893410984328098094321" > would give init a new key that is children WOULD inherit. > > Not sure what the permissions on that keys directory would be, I guess 700.
Eh, that would make leaks of key information easy.. Since most applications don't assume that something visable in a file name could be highly confidential information. :) Better to have the file in proc be an abbriviated keyid (some kind of smaller lossy hash of the key). To add you might echo "label:real key data" > /proc/1/keys/private/keys, and a file would appear named /proc/1/keys/private/label-123abcd which is a user defined label and the hash. Under no condition should a process be able to actually read the key data.. they can get the ID.. delete keys based on IDs.. etc. But they can't get the data.. otherwise a process could steal keys. If I take away a processes key from proc, there should be no way for it to get any further access to those files.. no chance that it could have hidden away a copy of that key. On 8/19/05, Hans Reiser <[EMAIL PROTECTED]> wrote: > I think it would make sense to put the keys as files in /proc: > > e.g. > touch /proc/1/keys/private/"0893410984328098094321" > would give init (aka process with id of 1) a new key that its children > would not inherit > > touch /proc/1/keys/inheritable/"1893410984328098094321" > would give init a new key that is children WOULD inherit. > > Not sure what the permissions on that keys directory would be, I guess 700. > > Hans > > Gregory Maxwell wrote: > > >On 8/18/05, Hans Reiser <[EMAIL PROTECTED]> wrote: > > > > > >>but the idea is to use keys instead of standard unix permissions.... > >> > >>I think you need to store keys in a per process place, and allow > >>specifying whether children of a process inherit the keys somehow. > >> > >> > > > >Oh, slick! > > > >I did not previously catch what the advantage would be to using crypto > >in the FS rather than just a crypted block device... minus some non > >critical niceties (like being able to use a random & per file IV is > >good from a security perspective.). > > > >Now I see what is possible, and I'm really excited. > > > >It will be interesting to see how a system with many keys performs.. > >most fast implementations of most crypto algs need a computationally > >expensive key setup which produces a fairly large working set of > >constants for encryption/decryption. > > > >With a per process structure there should be a way to revoke all > >instances of a key from all the other running processes that carry > >it.. or at least all processes of a specific user. Otherwise it will > >be too easy to accidental leave keys laying around. > > > >This per process crypto in the FS fits very nicely with a lot of the > >other recent security advances in the Linux world. > > > >Thanks for something new and exciting to talk about with my Linux > >using friends! :) > > > > > > > > > >
