|
[20080225]
|
Rationale on removing systrace from NetBSD
According to
www.systrace.org,
``Systrace enforces system call policies for applications by constraining the application's access to the system. The policy is generated interactively. Operations not covered by the policy raise an alarm, allowing an user to refine the currently configured policy. It is available for OpenBSD, NetBSD and Linux.''
Systrace was removed from NetBSD-current a few weeks ago, without
much discussion. Asking about what the rationale behind this was,
Christos Zoulas
explained:
``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.''
David Laight adds:
``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.''
With NetBSD's previous big-lock based SMP implementation and with
thread scheduling done in userland, the problem may have been not so
imminent. With NetBSD moving towards proper thread-scheduling and multiple
CPUs running inside the kernel, this becomes more and more of an issue,
and -- as sad as things are to lose systrace -- the step taken was
the right one. Anyone missing systrace feel free to fix the passing of
system call arguments as outlined by David.
[Tags: Security, systrace]
|
|
