Slashdot Mirror
When Not to Use chroot
Hyena writes "Linux guru Alan Cox is quoted as saying 'chroot is not and never has been a security tool' in a KernelTrap article summarizing a lengthy thread on the Linux Kernel mailing list. The discussion began with a patch attempting to 'fix a security hole' in the Unix chroot command, trying to improve the ability of chroot to contain a process. When it was pointed out that people have been using chroot as a security tool for years, another kernel hacker retorted, 'incompetent people implementing security solutions are a real problem.' A quick search on the terms 'chroot+security' quickly reveals that many people have long thought (wrongly) that chroot's purpose was for improving security."
The problem is that - for many root-running processes - running chroot has often been recommended as a security practice. This has often been the recommendation of the daemon authors, in the documentation, as a way to improve security.
I think that this was once (or may currently be) the case with bind and various MTA's. Standard practice for many daemons now is to start as root and fork as another non-privileged user, but not every daemon has this option.
Not for improving security, huh?
OK, genius, then explain why chroot() requires root privileges (or chroot capability) to execute.
It's only in the context of security that such a restriction makes any sense at all.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
So is the point of chroot safety rather than security? Ie. used to circumvent the "don't do stuff as root, because mistakes can have bad consequences" thing? I'm not intimately familiar with chroot, but this is how I understand it. It's possible to break out of a chroot jail (therefore don't use it for security), but it's unlikely that you'll do so accidentally (therefore feel free to use it for safety).
Is that about right?
https://portal.mytesting.org:8080/ (including)
* tinyHTTP (AppWeb, Apache, etc.)
* SQLite (MySQL, Postgres, etc.)
* [chroot-path-0]/www/html/*
* Other ([chroot-path-0]/usr/lib, [chroot-path-0]/bin, etc.)
and repeat...
https://my-test-env.org:8081/ https://my-test-env.org:8082/ https://my-test-env.org:8083/ https://my-test-env.org:8084/ Next, bind
Now you have 5 chroot'ed web environments to help your test team (of 5) speed up Alpha testing. May be fraught with bad security? That's not the point.
Basically chroot was an early attempt at virtualization. It allowed one to keep servers separated and contained, which improved reliability and availability. It has a minor positive effect on security, but not really all that much. There is a good argument to be made for not using chroot since it increases the maintenance effort, which frequently results in chrooted servers being neglected which reduces security. As for myself, I avoid using it, due to the maintenance issues.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
It doesn't make sense. Using chroot(2) for security is like trying to fit a round peg into a square hole that it was never intended to go into.
It also doesn't make sense that certain inbound TCP ports are restricted to being bound only by root, but that's the reality we have to live with.
<Thought-experiment>
Wrap your mind around the fact that it is Microsoft Windows userland now that causes most of its insecurity. If you could cleanly separate Microsoft Windows userland and run it under an Open BSD kernel, it would still be insecure. Conversely, if you could run an Open BSD userland under a Microsoft Windows kernel, it most likely would be more secure (sans Microsoft programming and design errors).
</Thought-experiment>
Chroot will not and cannot defend against the ill-advised practice of running binaries ("trusted" or not) received off host. Yes, I'm also looking at you Mac OS X, which is otherwise a lovely system.
Actually Bill Joy got it from AT&T.
My November 1979 edition of the CB/UNIX 2.3 manual pages has a chroot(1) and chroot(2) man page. It probably was not a CB add on and instead came from AT&T.
Here's the entire desccription of chroot(2)
NAME
chroot - change root directory
SYNOPSIS
chroot (rootname)
DESCRIPTION
Rootname is the address of the pathname of a directoyr, terminated by a null byte. Chroot
causes this directory to become the process root directory. This smeans that any references to
filename beginning with slash are not relative to the real root of the UNIX file system, but
relative to the new root directory specified in this system call. The current working directory
remains unchanged. Notice, however, that a chdir to slash ("/") following the chroot system
call wiill change the working directory to the new root directory. Arguments to chroot are always
absolute: no special meaning is given to initial slashes even if a chroot is currently in effect.
This system call is restricted to the super-user.
SEE ALSO
chroot(1)
DIAGNOSTICS
The error bit (c-bit) is set if the given name is not that of a directory or that is not searchable
(executable) or the current user is not the super user. From C, a -1 returned value indicates an
error, 0 indicates success
ASSEMBLER
(chroot = 61)
sys chroot; dirname
====
One of the things we used to chroot for was in support of buildiing many releases of our products, chroot pointed the compiler to the right set of files.