Re: signing a filesystem

Stephen C. Tweedie (
Wed, 1 Jan 1997 14:27:16 GMT


On Tue, 31 Dec 1996 06:53:53 -0800 (PST), "Andrew G. Morgan"
<> said:

> My primary purpose was to address the following question: when you reboot
> your system, how can you be sure that its filesystem is in the state it was
> when you last shutdown? ie. How can you be sure that someone hasn't booted
> DOS and used some disk editing software to modify the data on the disk?

The only real way is to encrypt your data. Authentication is not
really adequate, since it leaves the original data open and vulnerable
to attack --- and therefore leaves your authentication software open
to attack. The only way around this is to try to make some kind of
guarantee about the integrity of at least on part of your system
software, for example by using a secure boot floppy to set things
going. If you are booting off untrusted media then you aren't going
to be able to get the same level of security.

Encryption works better, because if your attacker cannot read the
original data, the job of editing the authentication software becomes
much harder. This would involve, say, a scenario in which a minimal,
unencrypted boot loader prompts for a password which would be required
before the rest of the system could be decrypted and booted. The
drawback here, of course, is that the same boot sectors could contain
a trojan attack.

In other words, security is very tricky if you can't trust your boot
media. You'd be better of just securing the machine, using a
combination of physical security and password-protection of the boot
environment, and using something like CFS plus MD5 to keep secure the
data that really matters to you.

> Gaining root access on a running system remains the problem that it always
> has been. But even CFS is vulnerable to root, who can simply replace the
> cfs-binaries with versions that log everyone's cfs-keys to a printer as they
> are entered.

True. POSIX.6 security goes a long way to minimising the potential
damage of a root attack, however. It still doesn't address the
possibility of an attack on the boot medium, though.

> This sort or vulnerability would require a more severe overhauling of the
> kernel. That may indeed be warranted, but is not likely to happen "over
> night". Digitally signing inodes is something that seems modular, it does
> not suffer from "encryption-problems" either so it could be safely included
> in the kernel source.

Digitally signing inodes would be a nightmare for several reasons.
First of all, if you can't trust your boot media then the kernel's
precautions are useless anyway (your attacker will simply replace the
kernel). Secondly, to verify the entire data contents would require a
complete file pass the first time every file was opened, which would
be less than ideal for performance. Finally, if you want on-going
protection (for paranoid safety from root-attacks), you need to be
_continually_ reverifying files; performance would be terrible.

IMHO, a far better solution would be to make sure that the system is
resistant to runtime root attacks in the first place, thus eliminating
the need for a complex in-kernel verification system. That way, you
can do the key-checking of any really important files during the boot
process, but from user programs, not the kernel.