lkml.org 
[lkml]   [1996]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: signing a filesystem
>  Since you have been thinking along these lines (and maybe getting ready
> to do something??), how about partitioning the security from the logic
> that manages the file system. (Sort of another plea to get people
> thinking along the lines of an external authorization facility).

Here is a paragraph from one of my previous messages which briefly covers the
topic, I don't know whether you missed it or whether it simply hadn't reached
your in-box before you sent the above:

What if we had some sort of security interface for the kernel? So a daemon
program could provide a security service to the kernel. The interface could
allow multiple daemons supporting different types of security. Then to mount a
secured filing system you would need to give the name of the encryption
algorithm to use and the password.


Now does that paragraph of mine match with what you were thinking of? Or
were you thinking about the MVS style authentication servers that other people
have been discussing (which is something I have not thought about and am not
really interested in - it'd be a great feature and I'd use it if it was there,
but I won't contribute code this decade).

I was thinking about having a security server application do a blocking read
of /dev/security. The kernel would then return it a block of data with
appropriate flags indicating whether it needs to be compressed or uncompressed
and containing it's password. Then the encryption server performs the
appropriate actions and writes the data back to /dev/security...


Russell Coker


PS Does anyone think it would be a good idea to have seperate mailing lists
for kernel design issues such as this and kernel implementation (IE debugging)?


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.146 / U:0.096 seconds]
©2003-2011 Jasper Spaans. Advertise on this site