Re: [gentoo-user] Is there a way to automate rsync of updated portage tree across multiple boxes without each having to pull it down from a gentoo mirror

[Vaeth]

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.