Yes, SELinux is complicated. It's much more expressive than chroot()+chdir(), and so it's possible to lock things in a much more find grained and secure way. The tradeoff is the complexity. Thats where tools like sandbox step in.
Posted Jan 6, 2010 3:34 UTC (Wed) by wahern (subscriber, #37304)
[Link]
Nice... for some limited set of apps, particularly desktop apps. Especially since it's more reasonable to expect desktop apps to be less portable than server apps. But I write server-side apps. Not only is this not especially useful on Linux servers, I still need to do sandboxing _inside_ my application both for portability, and because I still need privileges temporarily to setup my environment, such as open sockets. There're several app-specific privileged operations daemons typically need to do.
sandbox(1) uses a setuid utility. Anything which requires a setuid utility is already a red flag in my book. And such wrappers are inherently limited, anyhow.
These aren't generic solutions. They're interesting, useful, and laudable pieces of software, to be sure. But come on.... None of these things can even come close to the usefulness that traditional, portable unix privilege separation can accomplish. chroot, setuid, descriptor passing... these things are here now, ubiquitous, and time tested. Use them, developers. Security can't be an after-thought, bolted on, acceptable merely because it's described as a "security tool". The techniques needs to be tightly woven into the fabric of the code. (Alan Cox assertions are flat wrong; merely because chroot wasn't intended as a security tool doesn't mean it's not useful as such. Logic and history plainly prove him wrong, except that I personally think people take his quotes out of context anyhow.) Applications which don't do this need to be _fixed_, not amended. Additional steps, such as SELinux, VMs, etc, should be additive, not ends in themselves.
One nice thing about isolate(1) is that it uses a random UID. The code is awkward in places (I'd have just done `setuid(arc4random() | 0x80000000)', rather than a wierd loop, and anything w/ setuid mode is suspect, especially w/ all those machinations), but quite portable in theory, especially if Mach-O support could be added. And yet, at least for daemon apps, you can accomplish the same thing in about 10 lines of code if built into your app, w/o any dependencies. Sandboxing desktop apps involves special difficulties, but other than X11 and needing root privileges for chroot (I really wish systrace was built into the Linux kernel), all the same techniques apply equally well.
The isolate utility
Posted Jan 6, 2010 5:45 UTC (Wed) by drag (subscriber, #31333)
[Link]
Alax Cox's comments refer to why the fact that when people show up on the
LKML and bring up one of the obvious and blaring security defects with
Linux's Chroot implementation (and hope to see these 'problems' fixed) they
get ignored or shot down.
The isolate utility
Posted Jan 6, 2010 6:16 UTC (Wed) by drag (subscriber, #31333)
[Link]
Oh and he never said it was not useful. It's just that if the program has
root privileges then chroot is worthless. If you do it properly with
carefully controlled file discripters and proper setuid and that sort of
thing chroot can be useful, it's just much more difficult to get right then
it seems.
Meanwhile with things like BSD Jails, Linux LXC, or Solaris Zones are
designed to be easy for admins to make applications isolated in a proper
manner and can be used with lots of applications that would never really work
out with chroot.