Subject: Re: verified executable kernel modification committed
To: matthew green <email@example.com>
From: Brett Lymn <firstname.lastname@example.org>
Date: 10/30/2002 11:36:26
On Wed, Oct 30, 2002 at 02:12:22AM +1100, matthew green wrote:
> prolly, but the "securelevel > 2" bit gives me pause. why not just
> "securelevel > 1"?
> indeed. securelevel > 2 has never been defined before?
I looked at this just before I did the merge. Securelevel > 2 IS used
but it is not documented as far as I can tell. The sysctl code has a
check for securelevel > 2 in the code path for changing the core file
name for a process. On that basis I left my stuff as going totally
anal at securelevel > 2. I was quite prepared to change the code to
do this at securelevel > 1, it is not a big deal.
> i guess in the SAN situation i might buy this...
No, a SAN situation is dangerous because of the caching of the
fingerprint status. If you insist on running this over a SAN then I
would recommend using cgd to encrypt the disk to prevent the bits
on the hardware being twiddled. The verified exec relies on the
physical security of the hardware.
> i don't see how veriexec makes this
> inherently more secure. it probably has some nicer benefits over
> chflags, but nothing that should increase/decrease real security.
As I said, it gives a verification that what you think you are running
is what you are running, it is about ensuring the integrity of the
trusted computing base. Chflags can prevent files being modified but
it cannot tell you if it was tampered with as some stage before the
flags were applied.