Re: compat_hpux, systrace

David Laight <davidl8s.co.uk> writes:
> On Tue, Dec 25, 2007 at 12:13:55PM -0500, Perry E.
Metzger wrote:
>> 
>> The implementation of systrace is broken, but the
functionality it in
>> theory provides is of tremendous value -- being
able to constrain the
>> behavior of programs provides a very big tool for
securing software.
>> I would suggest that it would be important to think
of a way to
>> re-implement the functionality in such a way that
it worked correctly.
>
> That might be an aim, but it is extremely difficult for
anything like
> systrace to suceed if programs are trying to break the
security.
>
> For instance, even a non-threaded program can arrange
to call open()
> with the pathname in buffer memory that another process
can change
> between when the syscall control process reads the
pathname, and
> when the actual system call happens - so if argument
buffers might
> need to be rewritten, they must always be rewritten!

You're speaking of the current implementation as though it
were the
only way to do things. I agree that the *implementation* is
not good,
but the *functionality*, that is, allowing for the
interposition of
controls on each system call a process tries to invoke, is
both doable
and a good thing. Yes, there are details of the current
interface that
somewhat depend on use of the stack gap etc., but those
aren't really
something the user cares about -- what the user cares about
is being
able to do things like say "this process can only open
files in this
directory" or "this process can't run exec".
We can do that in any one
of several ways.

Please don't confuse the implementation with the
functionality. They're not the same thing.

> 1) threaded programs (use of stackgap)

We don't need to use the stack gap as the way to do things
like
systrace. Again, I agree that the way it is done now isn't
very good,
but the functionality provided is very powerful. It is nice
to be able
to cage a process so that, for example, a server program
that does not
ever need to call exec or open a file for write can be
prevented from
ever doing either.

Perry

> I agree that the *implementation* is not good, but the
> *functionality*, that is, allowing for the
interposition of controls
> on each system call a process tries to invoke, is both
doable and a
> good thing.

Unfortunately, while doable, it's very hard.  Everything the
controller
looks at must be passed to the kernel in a way that
guarantees that
what the kernel sees is data the controller has vetted.  For
simple
arguments that are passed in registers, this is easy.  For
self-contained strings like the pathname arguments to calls
like open()
or readlink(), it's a little more difficult, but not all
that much.

Cases like sendmsg(), where the argument points to a
structure that has
pointers off to other data, are even worse, the more so if
those other
pointers are conditional on something.  With driver-specific
ioctls
it's approximately impossible with our current kernel
setup.

To do this right, we'd have to arrange that copyin() and its
relatives
can be redirected so they get serviced by the controller
process, or at
least serviced from memory not writable by anyone else
during the
interval between the controller OKing the call and the
kernel reading
the memory.  And, of course, ideally analogous things should
be true
for data passing in the kernel->user direction too.

/~ The ASCII				der Mouse
 / Ribbon Campaign
 X  Against HTML	       mouserodents.montreal.qc.ca
/  Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3
27 4B