Messages in this thread |  | | From | bofh@snoopy ... | Date | Sat, 04 Jan 97 11:00:53 +1000 | Subject | Re: signing a filesystem |
| |
In <19970102204547.4217.qmail@test.legislate.com>, on 01/02/97 at 08:45 PM, rdm@tad.micro.umn.edu said:
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
|  |