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

What's the overhead?

[Drishmung]

What sort of performance hit does this impose? For instance, is it low enough to run nearly everything in the sandbox as a matter of course?

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.

Great news!

[Lomby]

This is really a great advacement for security. I hope it will be ported to Linux as soon as possible.

With this mechanism, basically every program can be sandboxed. Basically it would be very useful to restrict the access to the filesystem: applications do not need to access certain directories, or even better they should only access /home and /tmp.

Still the permissions should be defined mainly at system level: for example the mozilla binary must not be allowed to access /etc or /sbin for any user.

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:Great news!

[evilviper]

the mozilla binary must not be allowed to access /etc or /sbin for any user.

Hope you either use a http proxy or always type in IP addresses, or else you wont be surfing the web any more. /etc/resolv.conf is just one of several files in /etc that user-level processes use.

Re:Great news!

[adamsc]

This would be an excellent addition for a package management system - when you install foo.(deb|rpm) it could automatically put a set of sane defaults in some master directory under /etc which could be extended (or overriden if the sysadmin allows it) by a file in a similar directory (.sandbox?) in your home directory.

How does this compare to Jail?

[Anonymous Coward]

Does this isolate the programs from each other like Jail in FreeBSD or is it more of a system protection?

I've messed around with jail in FreeBSD and see there is a porting to Linux. Nice to see this in OpenBSD. Hey Microsoft, what have you got?

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.

Re:How does this compare to Jail?

[benhaha]

Running as System is NOT the same as running in Kernel space.

It means running without local security restrictions, and is precisely equivalent to running things as root. Administrator has reduced privilages compared to root or System.

The main (only?) reason to do this is if you need to do things with the privilages of other users, and even here NT provides proper impersonation facilities, so that's largely unneccessary if you are using an NT-supported authentication system, such as NTCR or X509 (I don't have a complete list, but you can write your own, like PAM in Linux -- if you trust yourself).

Also, FYI:

Internet Explorer runs neither in Kernel Space (I assume you mean kernel mode) nor as System, but as a user-mode process with the privilages of the user who started it.

The default installation of IIS has not run as System for about four years (maybe more, not sure, but at least four). Now it runs as IUSR_, which is a normal user and uses impersonation to check for file access privilages.

I don't know about Exchange, but I would be surprised if it ran a system these days.

Re:BSD vs. Linux

[Anonymous Coward]

"BSD: We've got hot babes."

Re:Lucent?

[evilviper]

Lucent making something similar to this a few years back that could encapsulate a binary to stop buffer overflows. I know that's not the same, but it is similar.

No, that's not even close. This monitors what the program is attempting to access, not monitoring buffers, return values, etc. Very different.

Highly portable?

[pdqlamb]

It's part of OBSD. You have to crank through a kernel mod to use it. And it's still "highly portable?" Sure, and command line Linux is "user friendly" and Winblows is "highly secure."