Subject: Re: compat_hpux, systrace
To: None <>
From: Perry E. Metzger <>
List: tech-kern
Date: 12/29/2007 14:16:28
David Laight <> 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.