Matthias Bethke wrote: > > > I'd say the vast majority of chroot jails are there for nothing > > > else but security. > > > > Alan Cox: "chroot is not and never has been a security tool", see e.g. > > http://kerneltrap.org/Linux/Abusing_chroot > > No disrespect to Mr. Cox but a silly argument stays a silly argument > even if brought forward by Alan. Programs like postfix certainly don't > use chroots for security because they were designed noobs or incompetent > people.
I did not cite the webpage because of the insults but because it shows how much the kernel programmers are interested in closing possible ways to break out of a chroot: not at all, because they think it is ok. That's why I said that _only_ with grsecurity a chroot _might perhaps_ be considered as a serious security measurement (but in fact, people which really need chroot to run binaries from two systems cannot activate these security enhancements). > Alan acknowledges that "Normal users cannot use chroot() > themselves so they can't use chroot to get back out" Yes, _this_ method of breaking out does not work without additional exploits like privilege escalation. (grsecurity closes a lot more methods; I did never reasearch which tricks might perhaps work as a user). But if everything works as it should, just running with low privileges does not make much of a difference than running with low privileges in a chroot: In any case you should only have access to those data which the privileges allow. (Admittedly there is a _slight_ increase in security: You might now be safe of ways of privilege escalation by bugs in certain SUID-programms). > That's not to say that setting up a vserver for each of > your programs exposed to the net wasn't *more* secure than a chroot That's a different topic, but a vserver might also even be more dangerous than doing nothing, because it has to be implemented (of course) with the highest available privileges, and so you have an additional risk of bugs (i.e. possible exploits) of the vserver - and in such a case the attacker has immediately the highest privileges. > but it's certainly a whole lot more secure if used > properly than not doing it at all. ...as is the usage of NAT as a "security feature". Of course, saying that using NAT or using chroot would not increase security at all would be a lie. But it is better to emphasize the dangers than to support the common misbelieve (as Alan alrady pointed out) that by using it there is no risk that "closed" ports can come through or that no other data than those in the chroot can be accessed. Remember the starting point of the discussion: The statement "rsyncd uses chroot, so an attacker can do nothing bad" is just false.
