lkml.org 
[lkml]   [1997]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: signing a filesystem
Date
Stephen C. Tweedie wrote:
> On Tue, 31 Dec 1996 06:53:53 -0800 (PST), "Andrew G. Morgan"
> <morgan@parc.power.net> 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.

Yes, this has already been agreed. I agree, booting off a floppy or a CD (in
the physical care of the sysadmin is the right way to set the ball rolling).
There are many ways to modify the hardware of a system to defeat even this
approach, but as usual the "cost" of such attacks is all that one can
hope to maximize.

> Encryption works better, because if your attacker cannot read the

But addresses a different concern. It would also be (legally) difficult to
freely distribute such stuff (and in some countries to use, France and
perhaps Germany too soon...). A case where encryption would tend to defeat
the value of the data stored on a medium is the case of a list of PGP public
keys, such information becomes less than worthless if its content is
restricted, but at the same time it is of prime importance to ensure that
such data is "correct".

> > 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.

1. I have been trying to find a decent reference for POSIX 6. There are no
books in print, and the "draft" docs available from NIST are dated 1994. Do
you/does anyone happen to know where I can get further information on this?

> 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

Given that we can trust our boot medium...

> 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.

This is not necessarily the case. Of primary importance is that the kernel
maintains an updated signature for each file -- not that it verifies it
*every* time. The record keeping need only be done at the time of physically
writing the the medium (the cache is "trusted"). So far as I can see, this
would be done when the inode was updated -- which happens anyway when the
atime for a file is modified.

The scheme I initially suggested of XORing the modified blocks' signatures
to update the signature for the file, would mean that only those blocks
that are written need be accessed - this of course happens anyway.

With extended-flags in the inode, if required, "verify-before-read" could be
provided on selected files, and with the addition of a "last verified" time
(together with signing the "inode" itself) this could be done once per
boot-session if-and-only if the file is accessed.

> 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

Making the system resistant to runtime attacks (by implementing POSIX 6 or
whatever) is without doubt of paramount importance. Signing the filesystem
following a root attack will be irrelevant given root's freedom to read
/dev/mem . However, this should not mean we cannot plan for a day when roots
identity is securely defended.

Remember, I intended this to be a protection for the system from attacks
when the kernel is *not* running. It is currently trivial for an attacker to
boot from a floppy, locate the binary for 'su' and simply replace it with
one providing him with a trapdoor.. digital signatures can guard against
this gaping vulnerability.

> 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.

I guess you mean at every boot _and_ every shutdown too. Since files change
during a session and this needs to be monitored. This is not practical.

I would maintain that the integrity of *every* file on a system is
fundamentally "important" to someone/some-process. There are also cases of
system-crashes where the normal "shutdown" procedure is bypassed. [ The
Orange Book discusses this in the context of "Trusted Recovery". Just
because it is a requirement for B3, it shouldn't be overlooked as out of the
reach of Linux... ;) ]

Best wishes (Happy New year to all by the way!)

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 ]

\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.079 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site