Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security Operating Systems BSD

A Highly Portable Sandbox Facility For OpenBSD 40

Posted by timothy from the hey-you-kids-can't-go-in-there dept.
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."
This discussion has been archived. No new comments can be posted.

A Highly Portable Sandbox Facility For OpenBSD More

A Highly Portable Sandbox Facility For OpenBSD

Comments Filter:

  • What's the overhead? (Score:3, Insightful)

    by Drishmung ( 458368 ) on Tuesday May 28, 2002 @09:52PM (#3599471)
    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?
    • 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.
      • I believe the simplest way to do this would be to use the ptrace(2) system call. You can specify that a process should be stopped before any
        system calls are made and then inspect the registers to see what the arguments to the system call are. This would naturally result in extra context switching every time a system call is made, but it is very simple and keeps the added complexity outside of the kernel.
  • I seem to remember 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. I'm too lazy to look for a link, so one of you karma whores (smnolde) can dig up a link.
    • 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.

  • Great news! (Score:2, Interesting)

    by Lomby ( 147071 )
    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.
    • 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.
    • 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? (Score:2, Interesting)

    by 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? (Score:1, Funny)

      by Anonymous Coward
      They have IIS, Exchange, and Internet Explorer running wholly in kernel space.

      Running programs as SYSTEM makes them fast!
      Whoops!
      Where's all my files!
      I are hacked!
      • 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.
    • 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.
  • Eventually binary-only software is going to become more and more common in Linux
    From a user stand point that should make things much easyer, but the core systems of all the differant Distros would need to be standardized in some way.. Or dependancy managment would have to be more automatic.. Even as a programmer I HATE having to compile packages when all I want to do is download and test an app.
  • This sounds like a great idea - however, on OpenBSD, how useful could this be? I don't know of any program that is released as a "binary-only" for OpenBSD. In Linux this could definately useful, as there are many binary only programs. It seems to me that with OpenBSD, you are basically required to compile. Which isn't really a problem - as long as you only want to use OSS.
  • This isn't a really novel project as it has allready been done by David Wagner and Tal Garfinkel. I highly recommend people read the Janus paper located at the bottom of this page [berkeley.edu]. They did something very similar although it uses some funny Solaris /proc interface hack. Notice that the paper presents the exact same idea for isolating web browsers. This Systrace mechanism seems a bit more complete though.
  • I like that idea, though I see would be a more useful thing in Linux or FreeBSD than in OpenBSD. For those of you that use NetBSD, there's an exec denier [netbsd.ro] (restircts specified users from executing things in /sbin, /usr/sbin, etc.) and there's a jail [netbsd.ro] module as well which restricts processes, such as jailing ssh and running top in an ssh session will disallow you to see other processes other than your own - Both of which are kernel modules (LKM).
    As for binary-only software in Linux, I don't believe the number of binary only applications will increase very much more other than commercial or restricted licensed apps.

  • "it is highly portable and can easily be integrated into GNU/Linux systems"

    Otherwise it wouldn't be newsworthy.

  • 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."

Slashdot Top Deals

Dynamically binding, you realize the magic. Statically binding, you see only the hierarchy.

Close