Messages in this thread | | | From | "Andrew G. Morgan" <> | Subject | Re: signing a filesystem | Date | Sat, 11 Jan 1997 12:32:14 -0800 (PST) |
| |
tytso@mit.edu wrote: > More generally, I have to ask the question why are we trying to do > cryptography at the filesystem level at all? What is your threat model?
Cryptography (for confidentiality) seems like a service better suited to a user level process: agreed.
> Who are you trying to protect your data against? What sort of resources > is your adversary going to have?
The original suggestion was to be able to "sign" the filesystem, the threat model was one of the following:
user process finds a way to modify the filesystem independently of the filesystem
attacker shuts down the machine and boots a rogue kernel (OS) that modifies the filesystem (replaces 'su' etc..)
system crashes and administrator wishes to establish which files' data was damaged
> It is not at all clear to me that the filesystem is really the right > place to be doing this sort of protection. Since the integrity > protection and signing is taking place in the kernel (and the > cryptographic keys have to present in the kernel at all times while it > is running), this scheme doesn't protect you against someone who has > managed to get superuser access. It only protects you against someone
Currently, there is no form of protection against a superuser.. From our discussions at USELINUX and the comments that Stephen Tweedie made, this is likely to improve in the future.
> who has physical access to your disk while the kernel isn't running. > However, is this a threat model which is most people will commonly see?
This is the sort of threat that a "public terminal" (universities/libraries etc..) are subject to...
Comments/thoughts?
Andrew -- Linux-PAM, libpwdb, Orange-Linux and Linux-GSS http://parc.power.net/morgan/index.html [ For those that prefer FTP --- ftp://ftp.lalug.org/morgan ]
| |