A Highly Portable Sandbox Facility For OpenBSD

An Anonymous Coward writes: "A new facility called 'systrace' has been developed by one of the OpenBSD developers. It allows enforcement of system call policies on untrusted binaries. For now it is only available OpenBSD-current, but the author claims it is highly portable and can easily be integrated into GNU/Linux systems. Eventually binary-only software is going to become more and more common in Linux, so this could be a another 'Good Thing(TM)' from the paranoids that brought us OpenSSH."

Comments

Re:What's the overhead?

[Espen Skoglund]

I can't imagine that the overhead is too large. As far as I can see, the intuitive way to implement this would be to generate a separate system call table for each sandboxed binary (i.e., in the same manner that you have separate syscall tables for running, e.g., emulated Linux binaries). This would impose no overhead on other executables and would for the most part not impose any overhead for the sanboxed binary either. A syscall which is unconditionally allowed simply works as usual. Other system calls like open(2) which often require a more complex test will have some overhead, though, but such open calls should not be in any time critical code anyway.

Re:Great news!

[Anonymous Coward]

Sandboxes are good for open sourced apps also. Ever seen a bug in an open sourced app? Yup, me too. Till those bugs get fixed, a sandbox will help ensure apps don't go tromping on files, accessing devices, spewing network packets, etc.

Re:How does this compare to Jail?

[benhaha]

Since Windows 2000 microsoft have had sandboxing of arbitrary processes with Job objects.

(FWIW, a Job object is a container for processes which can impose multiple restrictions on all children. Obvious, overdue stuff such as memory and processor quotas are included, but so is the ability to restrict which USER (windowing) objects a process can have access to. In principle this allows you to run untrusted GUI apps with lower privilages without the DOS/intrustion problems that come from features such as the clipboard, DDE, COM and so forth. Unfortunately you have to do this programattically, and MS don't appear to have done anything much with it yet from the perspective of the end user).

And of course system calls have always had restrictions on them, (though not on a per-function basis) via user rights.