Subject: Re: verified executable kernel modification committed
To: Brett Lymn <firstname.lastname@example.org>
From: Perry E. Metzger <email@example.com>
Date: 10/30/2002 09:26:34
Brett Lymn <firstname.lastname@example.org> writes:
> > Assuming the integrity of the files is verified immediately after
> > setting chflags,
> and assuming nobody ever changes it.... excuse me for being paranoid
> and not trusting things being left as I left them.
What prevents them from also altering the fingerprints?
To change the flags, you need to either bring things down to
securelevel 0 or you need to get access to the raw disk in some other
method. To change the fingerprints, you have the same requirements. It
doesn't seem to me that there is a real difference.
> > then verifying their integrity over and over again on
> > every exec really doesn't increase the real security of the system at
> > all (all other things being equal).
> It does not get verified over and over again. This is an important
> point, it is the reason why the system impact so low - the
> verification gets done the first time the exec is done, and after that
> iff the vnode has been put back into the free pool and reused.
So, again, why is this better/different from an immutable flag?
I'm not saying that the infrastructure isn't useful, by the way,
because I think it is -- just not for the "all files are local" threat
model. I believe it is mostly useful if you are dealing with a more
elaborate signing infrastructure and remotely mounted files, or with
proof carrying code.
> > So, in many case it would seem "smarter" to do the install, set chflags
> > to make the files immutable, and then just verify the integrity of the
> > files once, all while still in in single user mode, and be done with it.
> because it will not stop random executables being run (this includes
> putting a trojaned binary in a PATH).
I could do that with your stuff too though, couldn't I? The only way
to stop that is to a) know your PATH and b) make all directories in
that PATH immutable with chflags (or with your mechanism).
> It does not give you the ability of running shell scripts but
> prevent running the shell interpreter itself directly. Basically,
> this gives you a _visible_ means of verifying the trusted computing
> base - if there is something wrong it will be logged, chflags cannot
> do that for you. Also, this is done not only for binaries but
> scripts and for other arbitrary files.
Perry E. Metzger email@example.com