On Wed, Oct 30, 2002 at 10:08:36PM -0500, Perry E. Metzger wrote:
> 
> I'm not sure that there actually *is* anything better you can do here,
> thus my comment that I suspect chflags may be sufficient.
>

I don't think I am really getting across the idea properly... my
fault.
 
> 
> I have to admit I don't understand the distinction. You can choose not
> to have a file executable, and you can set the immutable flag as
> easily as you can add a fingerprint.
>

You may choose not to have a file executable but it is more difficult
to stop someone else who may choose to have their file executable on
your machine something like a DDoS zombie.  One of the things that
fired me up about doing this was the fact that the kernel would just
run any old thing that had the right format and permissions.  Verified
exec prevents this happening.
 
> OTOH, having the code path you've opened up might have some
> interesting other possibilities to it I've been thinking of.
> 

We can talk about that off line if you like.

> 
> Yes, you could, but this seems like a contrived idea -- there are
> likely simpler ways to accomplish such things, including simply
> chmoding the file and setting it immutable before raising the secure
> level.
>

Yes it was a bit contrived but if you only have a limited number of
machines and you want to build kernels then you do have the ability to
do that on the verified exec machine in single user but prevent access
to the build tools when the securelevel is raised.  The files are
still there, they will not execute because the fingerprints are not
there or... put the fingerprints there as file only fingerprints -
that stops the files being written to and prevents the binaries being
run.  That is much simpler than performing a chmod over all the build
tools and much less prone to errors.

I agree that some things can be done with chflags, some other things
may be done but will take a lot of work to setup and maintain.  I
believe that verified exec can simplify some complex things and
provides some facilities that cannot be emulated in other ways.  One
example of this is the prevention of the execution of a shell
interpreter directly but allowing the shell scripts that use that
interpreter to run.
 

> 
> Well, yes, if the immutable flag code is buggy you won't get
> confirmation, but your code is buggy the same is true.
>

heh - not touching that one.
 

> 
> chflags the login scripts for root to be immutable.
>

That fixes that but I wanted to paint a bigger picture, verified exec
quite simply blocks that entire class of attack - no more tricking
something into copying a binary setuid and running it, that will no
longer work.  If someone told me that I could fix problems one at a
time when they came up at random or put this in place and never have
that sort of problem again, I know what I would choose.
 
> Anyway, I do want to note that I don't think your work is useless here
> -- just that I'm no longer sure that the original intended use is as
> interesting as I once thought.
> 

Sure.  There is nothing mandatory about this, it is just a kernel
option.  We can talk about why it is not as interesting as you thought
offline if you like.

-- 
Brett Lymn