Subject: re: verified executable kernel modification committed
To: Andrew Brown <email@example.com>
From: matthew green <firstname.lastname@example.org>
Date: 10/30/2002 02:12:22
> Q: So, how do you stop the list being updated later?
> A: by using securelevel - the fingerprints can only be loaded at
> securelevel == 0. The full effect of the verified exec is in
> effect at securelevel > 2 (i.e. 3 onwards), at this point warnings
> about invalid/missing fingerprints become fatal errors, before this
> they were merely warnings.
>i assume that is "securelevel <= 0" ?
prolly, but the "securelevel > 2" bit gives me pause. why not just
"securelevel > 1"?
indeed. securelevel > 2 has never been defined before?
> Q: Doesn't chflags(1) do all this already?
> A: Not really. It can be used to do some of the work but there are
> some things it cannot do like prevent a file from being executed
> nor can it give any confidence that what you are executing has not
> been tampered with.
>how does it not give you confidence it has not been tampered with?
because now tampering with the underlying filesytem is evident,
whereas chflags doesn't protect you against that?
i guess in the SAN situation i might buy this... but in the local
situation, if this happens, it's either a bug or a local (physical)
problem that we can't avoid. 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.
(i'm sure that together they "raise the bar" further than either
does individually. also rasies the annoyance bar a lot further as
well i'd guess :-)