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!  This all
presupposes you can find somewhere in the processes address space to
actually put the modified buffer (and syscall args) that the process
(or one of its lwps, or other fiends) cannot modify. Currently the code
uses the 'stackgap' (memory between argv[] and the stack base), but that
is neither safe from being modified by another process, nor thread safe.

Some actions (eg access to priveledged TCP ports) can be handled by
finer grain 'root' privileged.

I'm not sure that the full horror of systrace can be implememnted!

Some places where it doesn't work:

1) threaded programs (use of stackgap)
2) threaded programs (use of members of struct proc)
3) compat32 (systrace is given a local copy of the argumemts)

	David

-- 
David Laight: david@l8s.co.uk