1A) 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.
1B) User files which work the same way as the above.
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 1B, 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.
>Be careful.
>For example, you left out any mention of files like .forward, .plan, and
>things like ~/public_html/, and you've left out any ability for users to
>cooperatively work on a project.
You'll notice I mention ~/web/* in section 3. I have just amended this to
refer to the new category 1A.
As for co-operatively working on a project, we could apply the security of
category 3 to groups as well as users. IE If a user is a member of a group
then there would be a copy of the encryption key for the group encrypted with
the user's key and stored in the system (IE stored in something similar to
/etc/shadow). Then when the user logs in their password is used to de-crypt a
copy of the group key which is passed to the kernel. Then the file system will
be capable of accessing files encrypted with that group key.
Russell Coker