Messages in this thread | | | From | bofh@snoopy ... | Date | Sun, 29 Dec 96 23:01:38 +1000 | Subject | Re: 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)?
| |