hubertf's NetBSD Blog
Send interesting links to hubert at feyrer dot de!
[20080225] Rationale on removing systrace from NetBSD
According to, ``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: , ]

Disclaimer: All opinion expressed here is purely my own. No responsibility is taken for anything.

Access count: 26526748
Copyright (c) Hubert Feyrer