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.

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

>  Neither actually gives an auditable event of the
> loss of integrity itself, just some indication of the possible window
> after the fact.
> 

Correct.

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

Yes, this should be logged.

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

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?

-- 
Brett Lymn