Hi Vaeth, on Wed, Sep 17, 2008 at 10:40:47AM +0200, you wrote: > > > 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 as root > : 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).
Sure, you can't expect that the Debian-loving friend you gave root on
your Debian-chrooted-on-Gentoo system will stay confined to that chroot.
Big deal, just don't do it. That's not what any sane person would
recommend chroot for anyway.
> > 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.
...which is usually pretty much everything in the bin directories, a lot
of stuff in /etc, and most importantly a shell. In a non-chrooted
program, an attacker who can exploit a bug can simply bind /bin/sh to a
port, run netcat, even use your compiler to prepare the next steps for
perhaps a local privilege escalation. In a chroot, nothing of the sort
is possible, you're limited to what you can do in your injected code.
> (Admittedly there is a _slight_ increase in security: You might now be
> safe of ways of privilege escalation by bugs in certain
> SUID-programms).
...plus safe from most information disclosure that would otherwise be
possible.
> > 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.
That's true, I just mentioned it because that's what Alan mentioned as
the true security tool.
> > 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.
Alan would probably emphasize the dangers of a seat belt and say
competent people used it only to keep their shopping bags from falling
over and not as a security tool because if you don't use it the
recommended way you can strangle yourself with it =^>
> Remember the starting point of the discussion: The statement "rsyncd uses
> chroot, so an attacker can do nothing bad" is just false.
Except that statement wasn't Neil's. To quote it correctly:
| In addition, the default rsyncd configuration with Gentoo uses a chroot
| jail. So even if you do allow connections to your portage tree, they
| won't be able to access anything else.
To summarize: for an attacker to be able to compromise a chrooted
rsyncd behind a NATting DSL router:
a) your ISP has to have a router configuration b0rked beyond belief
b) the attacker has to be aware of that and be able to distinguish
between your traffic and that of several hundred others that will
respond to his packets to 192.168.x.x
c) your router has to have a serious security hole
d) rsyncd has to be exploitable
e) your kernel needs to have a local privilege escalation bug
Now if that risk is worth the more complicated configuration using rsync
over ssh, I'm really not sure...I think I'd rather spend the time on
folding tin foil hats for the upcoming attack from Mars ;)
cheers,
Matthias
--
I prefer encrypted and signed messages. KeyID: FAC37665
Fingerprint: 8C16 3F0A A6FC DF0D 19B0 8DEF 48D9 1700 FAC3 7665
pgpEIWGy6o0sA.pgp
Description: PGP signature
