[ On Monday, November 4, 2002 at 12:28:19 (+1030), Brett Lymn wrote: ]
> Subject: Re: verified executable kernel modification committed
>
> On Sun, Nov 03, 2002 at 08:41:02PM -0500, Greg A. Woods wrote:
> > 
> > Which of course is easy enough to fix, as has been suggested already,
> > and I think such a feature should be implemented as a site-selectable
> > option regardless.
> > 
> > You can still easily reverify the integrity of files at any time after
> > you've set the schg flag on them.  Do it in /etc/security if you wish,
> > though for sure you'd want to do it after every reboot with the
> > signatures on robust read-only media....
> 
> Errr that was done a long time ago - it was called tripwire but
> because that is a userlevel process there are some problems with
> assuring that the file you think you are reading is the file you are
> reading.

Yes, and the very same vulnerabilities make verified exec just as
untrustworthy.  (not the same existing exploit implementations -- but
the same vulnerabilities that they excercise.  If an intruder can hide
from tripwire in a LKM then he can just as easily, more easily maybe,
hide from verified exec too.  verified exec only raises the bar for an
extremely short time against such vulnerabilities.)

> > You're still stuck with the granularity of the exec events, just as
> > verifying schg files only gives notice at the granularity of the
> > verification runs.
> 
> Correct - the thing is that the files you are more interested in are
> the ones that are used more often, they get checked more
> often... automatically.

You should not be more interested in the more frequently used files --
that's a fallacy.

>  Validating schg files gets you back to the
> old problem with tripwire - run too often and performance sucks, run
> too infrequently and you have a wider window for the cracker.

If somone is really fooled into thinking they are most interested in the
most frequently used binaries then they need only verify them more often
than the majority of other files, using whatever integrity checking tool
they choose.  But as I said, that's a fallacy.

Also, remember with schg and the appropriate securelevel we turn off
even root's ability to modify any of the files we care about.  With
added chflags violation logging and auditing we get immediate real-time
warning of attacks against any and all protected files.  We probably
really only have to re-verify their integrity after a reboot.

> Modulo the faults with tripwire (or it's ilk) being a userland
> process.  What I have done re-verifies the integrity automatically on
> the fly with little impact on the running system.  Why is that bad?

It's only bad in that it seems to be more code for almost zero gain in
overall security over what can be done with existing facilities.

For some scenarios I do really like the idea of having such checking
built into the kernel and done on open(2) so that any type of file with
"static" content can be verified just before it's used.  I don't want to
see your code taken out.  I'm just in agreement that it's not
necessarily a more secure scheme than what we almost have now with
chflags().

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>