[ On Wednesday, October 30, 2002 at 14:08:10 (+1030), Brett Lymn wrote: ]
> Subject: Re: verified executable kernel modification committed
>
> On Tue, Oct 29, 2002 at 10:19:55PM -0500, Greg A. Woods wrote:
> > 
> > Assuming the integrity of the files is verified immediately after
> > setting chflags,
> 
> and assuming nobody ever changes it.... excuse me for being paranoid
> and not trusting things being left as I left them.

Well, yes, that's why I said "all other things being equal".

If I have worries about the integrity of data on my disks then I want to
address that issue at the right level.  All my data matters, including
that which changes frequently, not just the images of my programs.

Indeed from a pure integrity perspective the programs I run are perhaps
the least of my worries in this case.  Corrupted programs are likely to
crash the very first time they are run, but corrupted data might leave
latent problems to grow and multiply for quite a long time before it's
discovered.

> It does not get verified over and over again.  This is an important
> point, it is the reason why the system impact so low - the
> verification gets done the first time the exec is done, and after that
> iff the vnode has been put back into the free pool and reused.

Yes, of course -- sorry for exaggerating.  I hadn't really forgot about
the significant optimisations in your scheme, but I did want to point
out that it was more of a detection system than a prevention system, if
that makes any sense.

> > So, in many case it would seem "smarter" to do the install, set chflags
> > to make the files immutable, and then just verify the integrity of the
> > files once, all while still in in single user mode, and be done with it.
> 
> because it will not stop random executables being run (this includes
> putting a trojaned binary in a PATH).

Well, as others have already said, if the PATH itself is carefully
controlled (which is indeed hard to do), then all the relevant
directories can be locked down with the schg flag.

>  It does not give you the
> ability of running shell scripts but prevent running the shell
> interpreter itself directly.

Yes, I think this is one aspect of verified execs which alone makes it a
valuable feature to have.

>  Basically, this gives you a _visible_
> means of verifying the trusted computing base - if there is something
> wrong it will be logged, chflags cannot do that for you.

Adding logging to detect attempts to modify files with the system/user
immutable (or append-only) flags set wouldn't be too hard.  I briefly
looked into doing it when I was adding coredump logging, but I didn't
really have a need for it at the time.

>  Also, this
> is done not only for binaries but scripts and for other arbitrary
> files.

Any file that doesn't change during normal operation can be verified to
be correct and then be set to be system/user immutable.  Even files
which do change can be somewhat protected with chflags -- eg. log files
can be set to be append-only.

I was just agreeing with MRG and trying to point out in another way that
as far as the integrity part of security goes this feature may not do
anything more to enhance security over what chflags can do.  (i.e. the
"in many case"s bit...)

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