[ On Monday, November 4, 2002 at 11:29:35 (+1030), Brett Lymn wrote: ]
> Subject: Re: verified executable kernel modification committed
>
> On Sun, Nov 03, 2002 at 12:50:47PM -0500, Thor Lancelot Simon wrote:
> > 
> > So what?  All that complexity, and you get... the same guarantee, with all
> > the same caveats, that you already had with file flags.
> 
> Actually you get the fact that eventually you will get notified the
> file has been overwritten, with file flags you will never know.

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.

> OK - I think that what I am doing is using some words that have
> different meanings to me - due to my work environment.  When I say
> "assurance" is that the system can be audited to be running correctly,
> this is not that you feel warm and fuzzy but that you can have an
> external party analyse your logs for anomalies.  What flags cannot
> give you is any visibility that something is wrong, you would never
> know if someone modified a file - you just assume that because the
> flags are applied then the file has never been modified, this is not
> assurance this is blind faith.

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

>  Verifying the hash of the file gives
> you a visible notification if a file has changed, this is an auditable
> event and gives you an indication that security has been breached.

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.  Neither actually gives an auditable event of the
loss of integrity itself, just some indication of the possible window
after the fact.

However with addition of the chflags violation logging that I and others
have suggested on several occasions you'd get auditable events on even
the very first attempt to violate the policy controls.  Logging and
auditing all [lf]chflags() system calls could even tell you if/when
someone tries to turn off schg.

> Show me how you gain assurance - by that meaning the ability to audit
> the system for correctness.

You can re-verify the integrity of the files whenever you wish, as often
as you want, using whatever tools you prefer.

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