Re: signing a filesystem
Thu, 02 Jan 97 13:12:32 +1000

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

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

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