What chroot() is really for
What chroot() is really for
Posted Oct 4, 2007 17:12 UTC (Thu) by wahern (subscriber, #37304)Parent article: What chroot() is really for
The advice to not use chroot() for "security" is just plain wrong. "Security" involves innumerable facets of programming. To say that because something doesn't address all of them simultaneously, and thus shouldn't be used at all, is... I can't even begin to describe how wrong that advice is. The proper way to use chroot() in a security-conscious application is:
chroot()
chdir()
setuid()
How simple is that? Is it fool-proof? Of course not. Neither is a program which fixes all of its out-of-bound memory accesses perfectly secure. But that doesn't mean one should counsel people not to fix the bugs.
One of the best rules of thumb in writing secure software is minimization: minimize the resources used; minimize the resources available; minimize privilege; minimize, minimize, minimize. chroot() fits perfectly into that paradigm.
When people starting thinking that its better to run a daemon inside VMWare because somebody suggests chroot() is useless shows just how misleading that advice was (and running VMWare isn't exactly minimization, either, when you consider you're adding millions of lines of code to your software stack). Just because unplugging your computer from the network is "more secure" than having an internet connection doesn't mean its either practical or even advisable. chroot() is practical and useful for enhancing the security profile of a Unix application, period.
That novice and ignorant programmers fall short of proper and sufficient use is neither a new phenomenon, nor reason alone to give such misleading advice.
Posted Oct 4, 2007 21:09 UTC (Thu)
by ckelso (guest, #43128)
[Link] (9 responses)
I don't disagree with the rule of least access. I just don't agree that chroot is enhancing the security of the daemon. If the daemon itself is insecure, you should simply not have it on your system, chroot or not.
Posted Oct 4, 2007 21:46 UTC (Thu)
by wahern (subscriber, #37304)
[Link]
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 (guest, #10563)
[Link] (4 responses)
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 5, 2007 15:47 UTC (Fri)
by jond (subscriber, #37669)
[Link] (2 responses)
Posted Oct 5, 2007 22:04 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
Then you'd probably want to make sure that loader isn't present in your chroot jail. I assume you're talking about glibc's ld-linux.so, which is an essential part of running programs that use dynamically linked libraries. Chroot jails I've seen have statically linked programs and don't need it.
Incidentally, if this is really an issue -- people want to have shared libraries within a chroot jail and still stop people from running programs they created themselves in /tmp -- it would not be hard to disable ld-linux.so's ability to run programs like that. The ability to exec ld-linux.so is a frill added to its basic function as a Linux program interpreter that runs when you exec something else.
Posted Oct 11, 2007 8:48 UTC (Thu)
by tbleher (guest, #48307)
[Link]
That was true some years ago. Nowadays ld-linux.so fails if it is called
Posted Oct 7, 2007 17:56 UTC (Sun)
by thedevil (guest, #32913)
[Link]
How do you enable per-user web directories (typically ~/public_html) if the webserver is chrooted?
Posted Oct 6, 2007 23:22 UTC (Sat)
by acorliss (guest, #3710)
[Link] (1 responses)
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.
Posted Aug 20, 2015 8:24 UTC (Thu)
by Wupme (guest, #104124)
[Link]
Because THIS
"should be able to get a list of accounts to attack on the system"
is security by obscurity. Which is worthless, just like changing SSH from Port 22 to lets say 1234246 or whatever.
"our comments suggest you've never actually had to support publicaly accessible systems, or understand information security."
No the one who doesn't understand even basic security is you.
"It certainly doesn't demonstrate your administrative competence."
Which is way higher than yours will ever be.
chroot doesn't add any security, and it was never designed for this anyway.
Posted Aug 20, 2015 15:28 UTC (Thu)
by raven667 (subscriber, #5198)
[Link]
LOL, WUT?
Are you saying that you only run perfect software that never has security relevant bugs on your systems, where do you find this perfect software and can I get some? If, like many of us, you run software which is imperfect then limiting its access to system resources when it gets exploited is useful to contain the damage, turning one problem of how to derail the software and take execution control of it, into several including how to escape the container if you want access to data other than what the application normally processes.
chroot() is a limited way to handle this, the first version of containers, there are better ways to do this now with VMs and Namespaces and SELinux and seccomp and Capsicum, etc. etc. which can make software, not impervious, but more resilient to complete security failure.
The only valid argument for using chroot is that you are ignorant or distrusting of your filesystem, user and group permissions. chroot isn't adding anything to the security of the daemon. Having a daemon running with a low access system account, what is the difference between having it in a chroot and not having it there? That's simple, access to things on the system that aren't known secure. It doesn't enhance your applications security at all. It mitigates your administrative incompetence.What chroot() is really for
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?What chroot() is really for
Chroot definetely has it's uses in the security field.What chroot() is really for
Non-executable /tmp can be trivially circumvented by calling the loader with your binary as an argument.What chroot() is really for
What chroot() is really for
Non-executable /tmp can be trivially circumvented by calling the loader with your binary as an argument.
> Non-executable /tmp can be trivially circumvented by calling the loaderWhat chroot() is really for
> with your binary as an argument.
on a binary on a non-executable mount.
>> 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. <<What chroot() is really for
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).What chroot() is really for
What chroot() is really for
What chroot() is really for