Re: CVS commit: src

[David Laight <david%l8s.co.uk@localhost>]

On Tue, Feb 19, 2008 at 03:04:34AM +0000, Christos Zoulas wrote:
> In article <alpine.DEB.0.999.0802190340010.13154%m2s05.vlinux.de@localhost>,
> Hubert Feyrer  <hubert%feyrer.de@localhost> wrote:
> >
> >On Mon, 31 Dec 2007, Andrew Doran wrote:
> >> Log Message:
> >> Remove systrace. Ok core@.
> >
> >Was there a rationale behind this decision published somewhere?
> >If so, where?
> 
> I am not sure where it has been mentioned but:
> 
> The current implementation has security issues resulting from using
> the stackgap to pass modified arguments to syscalls. This is is
> easier to understand with with multi-threaded programs: since
> systrace is using the stackgap to pass modified arguments to
> syscalls, a second thread can overwrite those arguments after
> systrace placed them but before the first thread executed the
> syscall. Fixing this would require a completely different mechanism
> to pass arguments to syscalls, perhaps having a wrapper for each
> syscall to accommodate systrace (and receive arguments in kernel
> space) and avoid TOCTOU races.

The big problem with the stackgap is that it was per-process, so in
a multithreaded program systrace would be trying to use the same
memory area for the modified arguments of more than one concurrent
system call!

The bigger problem is that, because systrace is used to enforce
security policy (rather than just trace process execution) is that
if systrace validates any user-space buffers (eg pathnames) it must
validate a copy that isn't mapped writably into the address space of
any other programs, and then pass the copy into the system call.
This is necessary whether the buffer is accepted as-is, or adjusted.

It is easy to see how a threaded program can circumvent such checks,
but it is also possible for a non-threaded program to arrange to
have a buffer area writable by another process.

Oh, and systrace has never been able to modify the arguments of netbsd32
(and linux32) emulated binaries.

        David

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