What chroot() is really for [LWN.net]

What chroot() is really for

Posted Oct 4, 2007 11:18 UTC (Thu) by petebull (subscriber, #7857)
In reply to: What chroot() is really for by pointwood
Parent article: What chroot() is really for

Learn and use SELinux. The wikipedia article has apparently a reasonable number of links for further information, apart from what is available in the entry itself.

to post comments

What chroot() is really for

Posted Oct 4, 2007 19:17 UTC (Thu) by sbergman27 (guest, #10767) [Link] (7 responses)

The problem I see with SELinux is complexity. The two rules I try to apply to both security and backups are:

1. Keep it simple.
2. Keep it clear.

SELinux, as powerful and useful as it can be when it is really needed, fails both of those tests for most applications.

What chroot() is really for

Posted Oct 4, 2007 23:07 UTC (Thu) by smoogen (subscriber, #97) [Link] (6 responses)

While this may not be the case in your post.. I see this argument used over and over again by people who have NEVER looked at SeLinux or tried to use it. They heard it somewhere else, or found a FAQ that said turn it off etc.. but never actually looked at it in any form.

What chroot() is really for

Posted Oct 5, 2007 4:04 UTC (Fri) by wahern (subscriber, #37304) [Link] (5 responses)

Why should they look at SELinux at all? The "least cost avoider" regarding software robustness is the developer, not the user. In other words, why do a million administrators have to lock down applications when the developer could have written the application better to begin with. Why are people arguing for solutions that put the onus on the user, AT THE EXPENSE of solutions which the developer can implement? I don't mean to say that SELinux shouldn't be used, but with limited time and resources, it seems to make sense to me to emphasize the measures developers can take.

Also, if SELinux were actually easy to use, why don't Linux distributions ship with policies that don't frustrate users? That's not to say it can't be done. It's only evidence that it can't be done well, yet. In my opinion, there's some key abstraction missing which, when discovered, will likely make MAC schemes more intuitive, automagically adaptable to the environment, and much more common place than they are. We just aren't there yet. The evolution of Unix tells us that only those interfaces which have proven themselves become standardized across platforms. For my money, compartmentalized environments a la BSD jails/Solaris Zones seem to be the wave of the future, even if personally I'd like to see MAC schemes become the norm.

Lost in this whole debate is something called portability. As a developer, I'm not going to write software with the expectation that the user will run it in UML or a BSD jail. Fact is, chroot is available on every single Unix system, with identical semantics. I'll write my software as best I can so that diligent users can run software in a jail, but just because others can or would isn't reason to persuade me not to use chroot.

What chroot() is really for

Posted Oct 5, 2007 12:38 UTC (Fri) by addw (guest, #1771) [Link]

why do a million administrators have to lock down applications when the developer could have written the application better to begin with.

Because security is best done in depth; ie multiple layers so that if one fails you hopefully prevent problems by another layer.

I am not saying that applications should not be well coded, but we need to be realistic and realise that all programs have bugs.

What chroot() is really for

Posted Oct 5, 2007 15:46 UTC (Fri) by jond (subscriber, #37669) [Link] (3 responses)

Because years and years and years of advisories have demonstrated to the sysadmin that this doesn't work.

What chroot() is really for

Posted Oct 5, 2007 20:29 UTC (Fri) by wahern (subscriber, #37304) [Link] (2 responses)

That chroot doesn't work? I can also point you to many advisories that have shown that chroot also contained an exploit. OpenSSH, BIND, Apache (OpenBSD), OpenNTP, djbdns, and qmail all use chroot, and the use of chroot has mitigated the impact of serious and widespread code exploits.

chroot is not _the_ answer. In all this debate, either here or on LKML, I have yet to see anybody mistakingly suggest that chroot _alone_ is a sufficient measure. All of these straw men arguments that say that chroot shouldn't be used because chroot _alone_ isn't sufficient are fallacious.

I'm only sticking to my guns because these forums are archived, and I don't want to see a student or junior engineer come to me in 10 years and say they didn't use chroot, though they trivially could have, because they were told it was useless.

What chroot() is really for

Posted Oct 6, 2007 1:40 UTC (Sat) by wahern (subscriber, #37304) [Link]

Oops. By "contained an exploit" I meant that an exploit was limited or curtailed, not that the chroot use itself was related to an exploit.
(Though, like any interface, chroot could feasibly be part of an attack vector. As described in this thread, use of chroot is questionable when an administrator has to duplicate sensitive files for a chroot'd environment.)

What chroot() is really for

Posted Oct 11, 2007 7:12 UTC (Thu) by gat3way (guest, #47864) [Link]

Nope, chroot() works and this is its expected behavior.

And BTW there are quite a lot of ways to escape it as long as you're already a root. You can for example mount filesystems on some occasions.

Who said chroot() must provide security...against someone that already has root privilleges on that system???