Messages in this thread |  | | From | bofh@snoopy ... | Date | Thu, 02 Jan 97 13:12:32 +1000 | Subject | Re: signing a filesystem |
| |
I have been considering the issues related to file system encryption. I think that we should firstly define a number of categories of security so that we have the option of considering them seperately. IE If there is a way of solving some potential problems then it need not be discarded because it doesn't solve all of them. I urge you to consider the issues I raise below and not to flame me on issues of neat kernel design and trivialities of implementation. Until we get the concepts sorted out there's not much point discussing implementation.
Here are some categories that I divide the files on my system into:
1) The first category IMHO should be the possibility of modifying/replacing system programs (/bin/*, /etc/passwd, and other critical files). With the exception of /etc/passwd these files are all read-only, and /etc/passwd can be safely considered read-only for small amounts of time. IE If the system has just recovered from a crash and /etc/passwd is read-only until the administrator enters a security key then I don't think anyone would be greatly inconvenianced.
2) System files which are read/write. This includes the contents of /var/spool/mqueue. These files have to be writable for the system to be fully operational.
3) User files (the contents of user home directories). These files are mostly never accessed when the user is not logged in. So they could be secured in such a way that they could not be read or written without the user's password. Some files in the user's home dir don't fall into this category, ~/web/* could be considered as category 1, and ~/.fingerlog is category 4.
4) User files that are written by system programs, eg /var/spool/mail/*. These files must be writable for append by system programs at all times for the system to be fully functional. But they need only be readable when the user is in some fashion logged in (could be logged in via POP or IMAP). NB Files which must be randomly written by the kernel don't fit this category.
Here are some possible ways of securing the files in the above categories (NB when I say "PGP" I mean any appropriate public/private key encryption system which works in the same way as PGP):
1) Encrypt the files with PGP, store the read key in LILO or give it to the kernel in some other type of boot parameter. The write key can only be given to the system by the administrator. In the case of /bin/* the administrator need only give the key when they want to replace such programs (which they presumably won't do often). In the case of /etc/passwd the administrator would have to supply the key before users would be able to change their passwords - I believe that in most real-world situations the users would accept "you can't change your password now because the system crashed last night and the administrator hasn't fixed it yet".
2) I can't come up with any solution for this.
3) You have to modify any login type programs (/bin/login, /usr/sbin/in.pop3d, etc) to give the kernel the password needed to en/decrypt the files as well as doing their usual jobs.
4) This could be handled by having PGP keys setup for each user. The user's public key would be used for writing the files (and would have to be readily available to the kernel), and the private key would be supplied when the user logs in. The way PGP works dictates that appending to the file would have to occur in a set of seperate records. For example you would end up with a series of records to the mail file for each message. Of course the program that reads the file would just see a normal file (and the kernel would be able to re-write and compact the file at read time).
For cases 1 and 4 we could assume that the system is in a trusted state and keep the passwords in memory after they have been entered once. For the specific case of the /etc/passwd file in case 1 this would have to be the case. This means for case 4 that the user mail files could be written in a normal fashion (IE no special append records that the filing system would have to maintain) after the user has logged in or done a POP mail check.
Russell Coker
|  |