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

Comments

Or is it?

[phorm]

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 security use?

[kcbrown]

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.

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.

Re:Then what is it for?

[soloport]

What's it for?

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 /proc to all 5. Then make a script to easily update them from SVN. Done.

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.

Overtaken by virualization

[flyingfsck]

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.