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.
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.