[ On Thursday, October 31, 2002 at 00:58:23 (-0500), Roland Dowdeswell wrote: ]
> Subject: Re: verified executable kernel modification committed 
>
> On 1035980536 seconds since the Beginning of the UNIX epoch
> matthew green wrote:
> >
> >this is not to say i don't find vexec useful.  i know several
> >systems that i will definately use it on.  i just don't think it
> >necessarily is inherently more secure than chflags protection.
> 
> Only if you hack your kernel to not execute files which do not have
> the schg flag set.  Otherwise, what's to stop you from executing
> other files?

Such hacks may not strictly be necessary.  In many cases through careful
control of the PATH setting and use of the 'schg' flag on all
directories in any PATH directory some assurance can be had that only
known pre-verified binaries are available to be run.

This doesn't stop arbitrary scripts from being run, but at least with
the basic POSIX scripting tool, /bin/sh, there's not a whole lot of
difference in the functional effects between a script and an iteration
of a bunch of commands with carefully controlled parameters, i.e.
scripts don't really let you do anything you can't already do by rote,
given a certain set of available underlying programs.

Obviously that's not so easy to do this on a general purpose system with
"normal" users, and anyone designing a special-purpose system in this
way has to be extremely careful that they don't make it easy for
something like a buffer exploit in some tool to turn their system back
into what effectively a general purpose system (eg. set the noexec mount
flag on all non-system filesystems, and watch out for interpreters that
can be run by such an attacker and which might be sufficiently capable
to make arbitrary system calls, etc., i.e. which could be used to
implement something like a DDoS or other attack tool).

The ability to run authorized scripts implemented in arbitrary
interpreted languages but to not allow the interpreter itself to be
invoked directly is a major feature of verified exec.  The same might be
done with kernel hacks to restrict the interpreter path prefix to a
place where direct execs are not allowed, but that kind of kernel
hacking isn't anywhere nearly so flexible.

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