What chroot() is really for

Posted Oct 4, 2007 21:46 UTC (Thu) by wahern (subscriber, #37304) [Link]

That's not a valid argument at all. Why? Because the PROGRAMMER makes the decision to use chroot, not the rest of the world. The real argument is, do you trust the diligence of the many thousands or MILLIONS of ADMINISTRATORS as a whole, not just the best ones; and do you believe yourself to be a perfect engineer incapable of making mistakes in your own code, or code you link against?

If you have reason to believe people might not keep the safest systems (like, maybe they just don't have the time to modify all the stupid SUID applications on a modern Linux installation), and if you are the least bit humble, then chroot()+chdir()+setuid()--if it fits the design and purpose of the application--is a valuable tool.

Security is a process, not a thing. No daemon in existence is provably secure (well; that's not technically true, because you can convert any piece of software to a mathematical function and make proofs, but I digress). You make small decisions when writing software which, in the aggregate, improve the robustness of the application substantively.

The problem is that people believe that using chroot is a hack. Its not a hack. By that measure, not running daemons as root is just as much a hack, because if its "insecure, you should simply not have it on your system". Using chroot is, on its own merits, a useful interface to marginally increase the robustness of your application. That's as much as you can say about anything when writing software, and its all the reason you need to use it. Plain and simple.

Also, this notion that you need to maintain a whole separate file system for chroot'd applications is nonsense. I've written dozens of daemons which can chroot into empty directories. Sure chroot'd Apache is a PITA if you're using Perl modules. In those cases clearly chroot conflicts with the functionality of the application. There are lots of these cases where file system resources, and process permissions create headaches. Many people--and companies--stubbornly run applications as root because its more convenient. Cases of idiots and cases where doing something is justifiable are not arguments for throwing away a technique completely.

Posted Oct 5, 2007 11:56 UTC (Fri) by Klavs (subscriber, #10563) [Link]

Chroot definetely has it's uses in the security field.

The apache example is a good one. One should always have several layers of security, and putting apache in a chroot is such a layer - and a good one at that. The "risk" of someone finding a bug in some website software is VERY high - even if it's your own software and you've been security conscious - we all make mistakes, and also new bugs is found in PHP and other languages all the time.

Also - it is a VERY good idea to mount /tmp none-executable (if in a chroot - there's a limit to what the executable can do though :) and to have a seperate DB-user for the user (ie. what the casual browser/internet user sees) and the admin section, and remember the principle of least privilege.

Posted Oct 6, 2007 23:22 UTC (Sat) by acorliss (guest, #3710) [Link]

No offense, but that's idiotic. There's many files on a system that are by design world readable (oh, say, /etc/passwd, for instance), and should be for regular users and processes. But that doesn't mean a process serving unknown and potentially hostile remote users should be able to get a list of accounts to attack on the system. Which is exactly the risk you should expect whenever you run a service that's designed to read files from a filesystem (like an http or ftp server).

Chroot isn't the be-all, end-all to this problem, but it's certainly a portable and effective tool that should be used along with others.

Your comments suggest you've never actually had to support publicaly accessible systems, or understand information security. It certainly doesn't demonstrate your administrative competence.