Slashdot Mirror

← Back to Stories (view on slashdot.org)

OpenBSD Gains Privilege Elevation

Posted by CowboyNeal on from the permission-granted dept.

ocipio writes "OpenBSD's systrace now has privilege elevation support. This means binaries no longer need to be suid or sgid an longer. Applications can be executed completely unprivileged. Systrace raises the privileges for a single system call depending on the configured policy."

24 of 309 comments (clear)

  1. Sounds like a (very) good thing by WolfWithoutAClause · · Score: 4, Interesting
    I've always hated the all or nothing priviledges that Unix uses.

    This sounds similar to a scheme that Java supports on some platforms (netscape?); I believe there is a setPrivilege() call.

    I'd like to see more of this kind of thing- restrictions to the file space that 'parts' of programs can access should be made, as well as I/O and networking restrictions. Is an email worm going to happen if the OS stops the macros from sending mail? Why should it if somebody else wrote the macro? There's a clear need for better granularity of security.

    We've seen how useful personal filewalls are for network interfaces- this needs to be extended to the other services that the OS supports.

    --

    -WolfWithoutAClause

    "Gravity is only a theory, not a fact!"
    1. Re:Sounds like a (very) good thing by Zeinfeld · · Score: 3, Interesting
      Java's one of the few programming languages that has security built in from the ground up.Wich makes me really wonder why the .NET runtime environment doesn`t do the same thing?

      Java was the first programming language to claim that security had been built in from the ground up. In practice the first versions of Java were not at all secure with lots of holes and a security architecture that was pretty clunky. Every call had a wrapper to check the privs separately, there was no security monitor concept, a single point of auditability.

      dotNET does have a strong security monitor concept and a very comprehensive security model. For details see Brian LaMacchia et al. ".NET Framework Security". And yes that is the same Brian who is talking on palladium in LCS today.

      I don't quite get what you mean by stating it would be good if IE only acceted dotNET attachments. Certainly it would be good if Outlook was written as dotNET managed code, or at least the attachment handling was. Then attachments could be run in restricted priv mode.

      The BSD hack appears to be much less sophisticated than Java or dotNET. It is really just adding back something that most security specialists have thought UNIX lacked all along, granular privilleges. The SUID hack has always been a kludge.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
  2. Re:Doesn't any READ ? by PotPieMan · · Score: 5, Interesting

    Same goes for X, which now no longer needs to be run SUID.

    Does this mean X will run slightly slower compared with an suid installation? It seems like there would be more code running behind each syscall to check the configured policy, but it's probably not a significant amount - at least, not for current systems. I'm merely curious.

  3. Interesting, but ... by yeOldeSkeptic · · Score: 4, Interesting

    how is this better than setuid, setgid? At least with setuid and setgid, control over system privileges is given on a per-application basis. With this per-system call method, the kernel somehow has to track each system call made by an application and grant or refuse privileges on some basis. (On what basis is unclear from the article.) This seems like a lot of data for a kernel to keep track of, considering the number of system calls a typical unix kernel has.

    Though I believe improvements to setuid, setgid is needed, per system call access privileges don't seem to be the right approach. I would much rather go with chroot jails for each application.

    1. Re:Interesting, but ... by Soko · · Score: 4, Interesting

      Yes, chroot jails are effective, but there are times when data - possibly sensitive data - has to be kept within the jail, or the daemon needs access to something outside the jail. Chrooting a secure HTTP server that is then compromised by a buffer overflow for example, would expose the files and databases that the HTTP daemon has access to. That is more easily a "get-out-of-jail-free" card than locking down single APIs.

      I would put forth that granting setuid via this method is more effective at securing systems, since you can more easily make sure that the API calls that need privs are written well and bullet proof. Minimal exposure to security risks is what we're after, right? So, this minimises the time that apps can expose themselves to major compromises, even more than a chroot jail. Both together means even better security.

      BTW, ACLs aren't much of a strain if done well - look at NTFS 5.1, which IMHO has ACLs done very well indeed.

      Soko

      --
      "Depression is merely anger without enthusiasm." - Anonymous
    2. Re:Interesting, but ... by jolan · · Score: 3, Interesting

      Setuid / setgid requires the program to do all it's privileged dirty work initially and then drop privileges to ensure a reasonable level of security.

      This new feature in systrace reverses the whole process. Now daemons can run totally unprivileged and systrace can escalate privileges as needed for only the calls that need it.

      It's not as taxing as you think it is. Yes, there is slow down, but for the huge blanket of security it adds, I think the hit in speed is offset by the benefits.

      Chroot jails for each application isn't necessarily feasible. Take Apache for example.

      Apache in OpenBSD 3.2 runs in a chroot jail and even the parent process is run as www:www.
      Some of the apache modules in OpenBSD ports were modified to be chroot-aware. Some are hopeless.

      Properly configured Systrace policies can make the aforementioned broken modules work again and reduces the need for chroot.

    3. Re:Interesting, but ... by Fweeky · · Score: 5, Interesting

      Blegh, will people please stop using "chroot jail" when they really just mean "chroot"?

      This is jail - a syscall which puts a process inside it's own process list, user list, IP and root directory, while limiting various syscalls which might make it possible (or at least easy) to escape the jail.

      This is chroot - a syscall which puts a process inside it's own root directory. As you said, this is almost completely unrelated to system-call security.

      chroot is not jail, jail is not (merely) chroot. Calling chroot "chroot jail" actually makes it *less* clear what you're talking about.

  4. This is a good thing? by LordOfYourPants · · Score: 5, Interesting

    If a flaw is found in the syscall lookups (ie: an app can make a sequence of syscalls to give itself priveledged access anyway) doesn't this mean literally any executable is capable of ruining your machine as opposed to only the suid root ones on any other *nix OS?

    Wouldn't a combination of both be better?

    1. Re:This is a good thing? by perry · · Score: 5, Interesting

      What you're saying is "if the mechanism itself has a horrible bug might that let you break security?" Well, of course.

      However, if there is some sequence of syscalls that lets you, say, get root, well, you have root, and the game is over. What systrace means is, if you have a system with a reasonably bug free set of system calls, you can reduce or eliminate the vulnerability that misbehaving root privileged programs might cause.

      As an example, is really far better for, say, your ntpd to only have the ability to run the normally root prived ntp_adjtime call rather than to be able to do anything root could do. Systrace also lets you give up the ability to run calls like fork and exec that a given program may not need (ntpd does not need them). That way, if someone remotely breaks ntpd, well, they don't own your machine -- at best they can crash your ntpd. They can't fork a new program (a typical exploit would fork a privileged /bin/sh), and they have no access to "normal" root prived calls.

  5. Re:Doesn't any READ ? by Cryptnotic · · Score: 3, Interesting

    Why not just make it SGID kmem (or mem or whatever group owns /dev/mem and/or /dev/kmem)?

    It seems like that would be as easy a way of partitioning "root-like" permissions as any other.

    --
    My other first post is car post.
  6. This is very very good. by Ulmo · · Score: 5, Interesting

    This is the first I've heard of Systrace privilege elevation. However, it seems to address what has historically been one of the greatest causes of security problems in Unix.

    If you look at the major vulnerabilities we've seen in Unix operating systems and software, they usually fall into one of three categories:

    1) Bugs in the kernel.

    2) Bugs in servers running with elevated privileges (often root).

    3) Bugs in suid binaries (often suid root).

    Privilege elevation could significantly reduce the problems caused by 2 and 3. It's by no means a silver bullet that's going to eliminate vulnerabilities, but it could produce a huge improvement.

    Consider how difficult it is to write a secure suid root binary. Not only do you have to be extremely careful about your own code, you have to worry about possible bugs in any of the libraries you link with. Some people (e.g. D. J. Bernstein) seem to have the knack of producing secure code first time, but even a good programmer who is always thinking about security can make the occasional mistake.

    With privilege elevation, such mistakes are no longer security disasters that grant complete root access to an attacker. The most an attacker can do is make the few privileged syscalls that are permitted by the systrace policy.

    --
    Lachlan.
  7. Question -- what if Apache code changes? by A+nonymous+Coward · · Score: 4, Interesting

    Suppose a new Apache version starts up differently, so the previous policy no longer matches. Perhaps Apache won't change that much, but there are certainly some apps which would need more complicated policies than Apache; what if they read config files in a different order, or add some new wrinkle? What about Perl or Python programs, where some module changes, or Perl itself changes?

    It would seem to me (as naive as I am to this new concept) that this could be a major pain in the butt. How much does this apply in practice?

    --
    Infuriate left and right
    1. Re:Question -- what if Apache code changes? by TheSHAD0W · · Score: 5, Interesting

      Very good point; and a new feature might require a new privilege setting, which would cause errors until the policy was redone.

      The policy also doesn't protect against exploits which use privileges that were already authorized, though it's still an improvement over SUID/SGID.

      It would be nice to add a CRC-32 to the policy file, and check the CRC each time the code is run. If a difference is discovered, indicating either a hacked executable or an upgrade, a warning could be given that the policy might need to be changed.

  8. Re:Explanation? by gehirntot · · Score: 3, Interesting
    That is a good remark.

    For system services that change privileges based on some internal state (like authentication), sandboxing does not work very well. In that case, you want to use Privilege Separation.

    On the other hand, if you have some global restrains, like root may never log in, you can use systrace to enforce them.

    A combination of both methods will give you a good fit.

  9. Re:Doesn't any READ ? by Saucepan · · Score: 5, Interesting

    Making the X server SGID kmem is still giving it far more privileges than it needs in order to be able to do its job. Just being able to read kernel memory is sufficient to get root in most cases (the easiest example to explain being reading the root password right out of the TTY buffers as root is logging on).

    Hopefully the new feature makes it into other OSes -- Unix has long needed a standard way of doing this kind of fine grained privilege separation.

  10. Re:Explanation? by BrookHarty · · Score: 4, Interesting

    Hey, interesting idea, how about expanding the policy to include which system calls, which level, and the amount of times they can use them.

    Don't know how CPU intensive, but after reading that Apache httpd ACL, you could really be anal and lock down applications. We currently use EFS on our Sun Boxes, and it locks down the boxes tighter than a drum. Sounds like a nice extension on a theme.

  11. ACL's, MAC's and more by fbsderr0r · · Score: 3, Interesting

    ACL's, MAC's and more http://www.trustedbsd.org/

  12. Re:Sorry but MacOSX is based on Mach kernel and so by Anderlan · · Score: 3, Interesting
    Huh?

    http://www.apple.com/macosx/jaguar/unix.html
    ... Jaguar integrates features from state-of-the-art FreeBSD 4.4...

    --
    KLAATU, BORADA, NIh*ahem*
  13. What is the policy? by njchick · · Score: 3, Interesting
    Sorry for stupid question, but I cannot find any explanation of how the policy is configured. What should the program do to authenticate with the kernel and get the permissions defined in the policy?

    Using the executable file of the process would be dangerous because the attacker could use compromized shared libraries. Any passwords would require changes in the software (i.e. you'll have to recompile apache so that it could authenticate).

    The only thing I can think of is a token in the process environment that can only be set by root (maybe an additional group ID). So apache would still have to be run by a program with root permissions (init script) to be able to listen to port 80.

  14. Re:Doesn't any READ ? by lukew · · Score: 5, Interesting

    A little offtopic, but a great security approach that I haven't seen used to often is to port-forward port 80 to a non priviledged port Apache is running on (Say, 8080). Completely removes the need for root privs.

  15. Using ssh to rid oneself of suid/sgid by OoSync · · Score: 4, Interesting

    I've used ssh to rid myself of things like "su -l" and "sudo" before. I think the basic idea can be used to get rid of necessary suid/sgid programs with elevated permissions. The basic theory is each application is actually called by a wrapper using ssh. Public keys from the application's user or group (root, apache, wheel, etc.) are provided to a user with genuine need to access these apps and placed in the ~/.ssh/authorized_keys(2) file. Then the user's public key is provided to the application user's ~/.ssh/authorized_keys(2) file. When the user calls the application, they are allowed access using RSA key authentication. No need for blind SUID/SGUID apps as only those users who need to use it have the permission. Furthermore, these permissions can be easily revoked by a.)changing the app's private/public keypair without providing them to the user, or b) commenting/deleting the user from the authorized file. Additionally, with ssh-agent, keychain, and authorization forwarding, these priveledges can be locked down tight. I'm not sure if openssh authorization forwarding will allow the authorization to be okayed from a remote machine. Just a random thought that seems appropriate here. Let me know what you think.
    --Wes

    --

    I always get the shakes before a drop.
  16. EROS: The Extremely Reliable Operating System by Anonymous Coward · · Score: 5, Interesting

    Security in UNIX can be messy. It is hard to add security late in the prosses without making it hard to use and understand.
    EROS (GPL) was designed for fine tuned privileges from day one. This is a natural part of the capability system.

    "EROS is a pure capability system. Authority in the system is conveyed exclusivly by secure capabilities, down to the granularity of individual pages."

    This is a secure design and a OpenSource OS.
    http://www.eros-os.org/

  17. Assumptions by nuggz · · Score: 3, Interesting

    Existing programs will assume that if a process demonstrates one privilege that traditionally only a root process posesses, then it must also have all the others

    Assumptions cause trouble, lets assume that this buffer is "more than big enough for anything someone will put in there", that worked out REALY well didn't it?

    A proper program should check for each individual requirement, and act appropriately. Bad code has lots of assumptions, an assumption is a bug that hasn't been found yet.

    Most of my code isn't proper, I'm lazy.

  18. Don't get me wrong, I like capabilities security.. by scrytch · · Score: 5, Interesting

    But really, it needs to get out of the ivory tower and start giving us examples that work. The Confused Deputy is about compilation, sounds like it was an issue from a VAX box from the 80's, and not only is so utterly irrelevant to Joe User, it's not even all that terribly accessable a metaphor to people using gcc!

    The erights folks are using more accessable examples (a web browser), but in their examples paint a picture of the land of popup hell, where every app has to ask to do every single operation. Write to one file, one popup. Write to another file, another popup. Open your address book, another popup. Experience shows that users click "yes" or "ok" on popup dialogs or whatever button they can just to make the damn things go away and make them stop coming back. My own mother would ask me, "how do I keep this from asking me these questions all the time?".

    I know it doesn't have to work this way -- an installer can give an app a pre-set list of capabilities that one should be able to verify, log, change, audit, revoke, etc. Roles can be created out of capability groups to put some of the ease of ACL's back into the equation. But their their own example stories don't even make that clear. It's ivory tower, all about security theory without an ounce of human factors other than "the user will learn" and some laughable user education story about POLA.

    The average server is reasonably secure right now, since it performs dedicated tasks and is administered by what one presumes are trusted people. It's the desktop that's providing fertile ground for attacks. Thousands of infected desktops hitting one server, and well, wouldn't it be nice if those desktops were secure? They won't be if security doesn't take the human factor into account.

    --
    I've finally had it: until slashdot gets article moderation, I am not coming back.