setuid alternatives

Discussion in 'all things UNIX' started by Gullible Jones, Feb 19, 2013.

Thread Status:
Not open for further replies.
  1. Ah, the setuid hack, everyone's least favorite thing about UNIX. It's ugly, it's kludgy, it opens up lots of potential security holes...

    So of course I'm wondering if there are better ways of handling privilege elevation.

    What I know of so far:

    POSIX Capabilities

    Covered already in another post. Supported by Linux and apparently by FreeBSD, been around since ~2002. Allows binary executables to run with only specific aspects of root privileges. No idea why nobody uses this... OTOH it's still based on file attributes, which probably introduces some of the same issues as setuid.

    Systrace

    A dinosaur from the distant past, basically a (fully graphical) HIPS for UNIX OSes. Can be used in place of setuid/setgid. But it hasn't been updated in ages, and the vast majority of UNIXes have abandoned it with the advent of modern MAC implementations.

    What I suspect might work:

    SELinux

    Based on what little I know about it, I think it should be able to grant elevated privileges as well as removing privileges.. Whether that's a good idea is another matter entirely.

    An arbitrating daemon of some sort

    This is how Windows 2000/XP handles privilge elevation - a privileged daemon that processes requests from unprivileged users. This sounds sensible, but in view of the infamous shatter attacks on XP, it may not be any better.

    What other ways are there of dealing with the need to elevate user privileges on UNIX? In theory, or in practice? And which of them have actually be implemented?
     
  2. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    Just a note on Capabilities, they're not as nice as you'd think. Most capabilities can be easily abused to give full rights.

    But what is, exactly, the issue/ the goal? Can't answer much without knowing.
     
  3. Thanks for the warning re capabilities.

    Issue? Basically that, as I understand it, setuid binaries are a large source of security holes - they may be introduced via mounted filesystems under certain conditions for instance. And I would think they'd be easier to fuzz than a daemon, though I'm not certain.

    BTW I realize this is not very relevant on desktops, but it is very relevant on multiuser systems.
     
  4. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    Well, you can restrict setuid binaries with capabilities and any LSM, root is easily confined in something like apparmor/ SELinux. That's why so many services on Ubuntu run with Apparmor.

    Many of these programs drop privileges immediately, and chroot themselves. That's pretty typical too. If you use Grsecurity you can confine root in a chroot.

    Basically anything that confines your typical program can confine a setuid program, except the default DAC permissions.

    In terms of fuzzing neither is easier or harder than another though.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.