Slashdot Mirror


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

40 comments

  1. What's the overhead? by Drishmung · · Score: 3, Insightful

    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?

    --
    Protoplasm. Quiet Protoplasm. I like quiet protoplasm.
    1. Re:What's the overhead? by Espen+Skoglund · · Score: 3, Informative

      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.

    2. Re:What's the overhead? by ghassanm · · Score: 1

      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.

  2. BSD vs. Linux by Anonymous Coward · · Score: 0, Funny

    BSD vs Linux:

    They say a picture is worth 1000 words. I'll let the pictures do the talking.

    Look who shows up when BSD users get together. Now look what happens when Linux users get together. That's right! They immdiately start buggering each other! This picture shows the reaction of the receiver of such activity. A smile from ear to ear.

    Note the look of disgust when a member of the BSD crowd actually has to look at a Linux user. Truly truly sad.

    1. Re:BSD vs. Linux by Anonymous Coward · · Score: 2, Funny

      "BSD: We've got hot babes."

    2. Re:BSD vs. Linux by Anonymous Coward · · Score: 0
      "BSD: We've got hot babes."

      Heh, when everything's said and done, what else really matters? :P

  3. Lucent? by akharon · · Score: 1

    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.

    1. Re:Lucent? by evilviper · · Score: 2
      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.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
  4. Great news! by Lomby · · Score: 2, Interesting

    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.

    1. Re:Great news! by Anonymous Coward · · Score: 0

      I don't understand what's great about this!"OPEN" source software will forever have the source so a Binary file sandbox would only benefit some closed source app which wont allow access to source. In which case the company would be held accountable for whatever nastiness the application caused anyway. I think that people hear security and get to caught up. I remember when HTML, HTTP, were buzzwords. Now crypto, ultra secure this and encrypted file systems are the new ones.

    2. Re:Great news! by Anonymous Coward · · Score: 2, Informative

      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.

    3. Re:Great news! by Anonymous Coward · · Score: 0

      I hope it will be ported to Linux as soon as possible.

      Given the 190+ linux versions, and people willing to go from version to version for 'this feature or that widget', why not move to OpenBSD for this feature?

    4. Re:Great news! by evilviper · · Score: 2
      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.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    5. Re:Great news! by adamsc · · Score: 2

      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.

  5. How does this compare to Jail? by Anonymous Coward · · Score: 2, Interesting

    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?

    1. Re:How does this compare to Jail? by Anonymous Coward · · Score: 1, Funny

      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!

    2. Re:How does this compare to Jail? by benhaha · · Score: 2, Informative

      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.

      --
      NO ID: BEING FREE MEANS NOT HAVING TO PROVE IT
    3. Re:How does this compare to Jail? by benhaha · · Score: 2, Insightful

      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.

      --
      NO ID: BEING FREE MEANS NOT HAVING TO PROVE IT
  6. Could be a long time comming by BagOBones · · Score: 1
    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.
    --
    EA David Gardner -"... but the consumers have proven that actually what they want is fun."
  7. Cool, but... by jfeasel · · Score: 1

    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.

  8. Slashdot is dying by Anonymous Coward · · Score: 0

    (Reposted from an earlier story -- worth reading.)

    It is now official - a Slashdot poll has confirmed: Slashdot is dying

    Yet another crippling bombshell hit the beleaguered Slashdot community when recently a poll on the site confirmed that up-to-date and factually-correct stories account for less than 40 percent of all submitted news stories, that the user-moderation system has fallen to pieces through the oppressive power of the editors, and that subscribers don't need to pay and can use such software as JunkBuster to filter out adverts. Coming on the heels of the latest MSNBC survey which plainly states that Slashdot has lost more readers, this news serves to reinforce what we've known all along. Slashdot is collapsing in complete disarray, as further exemplified by failing dead last in the recent Kuro5hin technology site popularity test.

    You don't need to be a Kreskin to predict Slashdot's future. The hand writing is on the wall: Slashdot faces a bleak future. In fact there won't be any future at all for it because Slashdot is dying. Things are looking very bad for the site. As many of us are already aware, Slashdot continues to lose readers. Red ink flows like a river of blood. The subscribers scheme is the most endangered of them all, having lost 62% of its paying readers.

    Let's keep to the facts and look at the numbers.

    Slashdot editor and homosexual-rights campaigner Rob Malda (CmdrTaco) states that there are 700 paying subscribers to Slashdot. How many normal readers are there? Let's see. The number of subscriber versus reader posts on Slashdot is roughly in ratio of 1 to 4. Therefore there are about 700*4 = 2800 normal casual readers. Anonymous Coward posts are about half of the volume of the typical posts. Therefore there are about 1400 readers who can't be bothered setting up an account. A recent article put the Trolls, who post sexual insults, foul ASCII art pictures and links to vile sites, at about 80 percent of the Slashdot readership. Therefore there are (700+8400+4200)*4 = 19600 trolling readers. This is consistent with the number of Troll posts.

    Due to the troubles of Andover.net, abysmal hit counts and so on, Slashdot went out of business and was taken over by OSDN who run another troubled site. Now OSDN is also dead, its corpse turned over to yet another charnel house.

    All major surveys show that Slashdot has steadily declined in readership. It is very sick and its long term survival prospects are very dim. If Slashdot is to survive at all it will be among geeky hobbyist dabblers. Slashdot continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, Slashdot is dead.

    So why now? Why did Slashdot fail? Once you get over the myriad of incompatible personalities, particularly among the editors who have repeatedly failed to check for serious inaccuracies in their stories (see the FreeBSD 4.5 "release" as a shocking example), it's clear that subscribers will continue to decrease. Using software such as JunkBuster, readers can eliminate adverts without having to pay any money. These two significant factors, along with the corrupted "moderation" scheme (where editors have infinite power over the regular moderators), only confirm yet further that Slashdot's glory days are coming to an end.

    Fact: Slashdot is dying

  9. been done... by ghassanm · · Score: 1

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

    1. Re:been done... by Anonymous Coward · · Score: 0

      And it's under a BSD license, the other implementations were too restrictive for the OpenBSD source tree (GPL is no-go).

  10. security in BSD by spunkykuma · · Score: 1

    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 (restircts specified users from executing things in /sbin, /usr/sbin, etc.) and there's a jail 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.

  11. Re:Could be a long time comming (sic) by TeaDaemon · · Score: 1

    Isn't that what the Linux Standards Base is for?

    IMHO, however, I almost always compile from source, especially with a new piece of software, though if you're running less powerful hardware it can be a bit of a drag.

  12. Thank God by Groganz · · Score: 1

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

    Otherwise it wouldn't be newsworthy.

  13. UML by Anonymous Coward · · Score: 0
    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.

    User Mode Linux

  14. Highly portable? by pdqlamb · · Score: 2

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