What chroot() is really for
What chroot() is really for
Posted Oct 4, 2007 10:29 UTC (Thu) by pointwood (guest, #2814)Parent article: What chroot() is really for
What is the recommended tool/way/option to use instead?
Of course, there is VmWare, etc., but it would be nice to have something like this for a ftp/sftp server, etc.
Posted Oct 4, 2007 11:18 UTC (Thu)
by petebull (subscriber, #7857)
[Link] (8 responses)
Posted Oct 4, 2007 19:17 UTC (Thu)
by sbergman27 (guest, #10767)
[Link] (7 responses)
1. Keep it simple.
SELinux, as powerful and useful as it can be when it is really needed, fails both of those tests for most applications.
Posted Oct 4, 2007 23:07 UTC (Thu)
by smoogen (subscriber, #97)
[Link] (6 responses)
Posted Oct 5, 2007 4:04 UTC (Fri)
by wahern (subscriber, #37304)
[Link] (5 responses)
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.
Posted Oct 5, 2007 12:38 UTC (Fri)
by addw (guest, #1771)
[Link]
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.
Posted Oct 5, 2007 15:46 UTC (Fri)
by jond (subscriber, #37669)
[Link] (3 responses)
Posted Oct 5, 2007 20:29 UTC (Fri)
by wahern (subscriber, #37304)
[Link] (2 responses)
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.
Posted Oct 6, 2007 1:40 UTC (Sat)
by wahern (subscriber, #37304)
[Link]
Posted Oct 11, 2007 7:12 UTC (Thu)
by gat3way (guest, #47864)
[Link]
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???
Posted Oct 4, 2007 15:09 UTC (Thu)
by ebiederm (subscriber, #35028)
[Link]
That can give the same effect as chroot but without being able to escape.
For even more strength one of the linux security modules like AppArmor or
For more support making an application look like it has the box to itself
Posted Oct 4, 2007 22:18 UTC (Thu)
by dowdle (subscriber, #659)
[Link] (1 responses)
For Linux there is OpenVZ and/or Linux-VServer... as well as the container features that have already made it into the mainline Linux kernel... and additional code that is expected to make it into the mainline kernel in the next year or so.
Anyway, if you want a quality isolation (and OS Virtualization as well), you can do so with OpenVZ and/or Linux-VServer. Of course both of those require a modified kernel... but they do work well, are mature, and offer additional features like resource management, separate root user and accounts, and in the case of OpenVZ, checkpointing (offline and online/live migration).
Posted Oct 5, 2007 3:34 UTC (Fri)
by jordanb (guest, #45668)
[Link]
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.
What chroot() is really for
The problem I see with SELinux is complexity. The two rules I try to apply to both security and backups are:What chroot() is really for
2. Keep it clear.
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
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.What chroot() is really for
What chroot() is really for
why do a million administrators have to lock down applications when the developer could have written the application better to begin with.
Because years and years and years of advisories have demonstrated to the sysadmin that this doesn't work.What chroot() is really for
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.What chroot() is really for
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.What chroot() is really for
(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.)
Nope, chroot() works and this is its expected behavior.What chroot() is really for
Look at the mount namespace in the kernel.What chroot() is really for
Selinux can help.
the ongoing work on namespaces can help. Ultimately though while the
namespaces can help improve security just like chroot that isn't their
primary point.
The article mentions FreeBSD jails and how their chroot jail is a mini-virtualization.What chroot() is really for
UML has been in the kernel for a long time and works great. What chroot() is really for