Re: Basic interface for key management in reiser4 (DRAFT)

[Gregory Maxwell <gmaxwell@gmail.com>]

On 8/19/05, Hans Reiser <reiser@namesys.com> 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 <reiser@namesys.com> 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 <reiser@namesys.com> 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! :)
> >
> >
> >
> >
> 
>