Gentoo Archives: gentoo-user

From: Vaeth <vaeth@××××××××××××××××××××××××.de>
To: gentoo-user@l.g.o
Subject: 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
Date: Wed, 17 Sep 2008 08:41:10
1 Matthias Bethke wrote:
3 > > > I'd say the vast majority of chroot jails are there for nothing
4 > > > else but security.
5 > >
6 > > Alan Cox: "chroot is not and never has been a security tool", see e.g.
7 > >
8 >
9 > No disrespect to Mr. Cox but a silly argument stays a silly argument
10 > even if brought forward by Alan. Programs like postfix certainly don't
11 > use chroots for security because they were designed noobs or incompetent
12 > people.
14 I did not cite the webpage because of the insults but because it shows
15 how much the kernel programmers are interested in closing possible ways
16 to break out of a chroot: not at all, because they think it is ok.
17 That's why I said that _only_ with grsecurity a chroot _might perhaps_
18 be considered as a serious security measurement (but in fact, people
19 which really need chroot to run binaries from two systems cannot activate
20 these security enhancements).
22 > Alan acknowledges that "Normal users cannot use chroot()
23 > themselves so they can't use chroot to get back out"
25 Yes, _this_ method of breaking out does not work without additional
26 exploits like privilege escalation. (grsecurity closes a lot more methods;
27 I did never reasearch which tricks might perhaps work as a user).
28 But if everything works as it should, just running with low privileges
29 does not make much of a difference than running with low privileges in
30 a chroot: In any case you should only have access to those data which
31 the privileges allow. (Admittedly there is a _slight_ increase in
32 security: You might now be safe of ways of privilege escalation by bugs
33 in certain SUID-programms).
35 > That's not to say that setting up a vserver for each of
36 > your programs exposed to the net wasn't *more* secure than a chroot
38 That's a different topic, but a vserver might also even be more
39 dangerous than doing nothing, because it has to be implemented (of course)
40 with the highest available privileges, and so you have an additional
41 risk of bugs (i.e. possible exploits) of the vserver - and in such a
42 case the attacker has immediately the highest privileges.
44 > but it's certainly a whole lot more secure if used
45 > properly than not doing it at all.
47 is the usage of NAT as a "security feature".
48 Of course, saying that using NAT or using chroot would not increase
49 security at all would be a lie. But it is better to emphasize the
50 dangers than to support the common misbelieve (as Alan alrady pointed
51 out) that by using it there is no risk that "closed" ports can come
52 through or that no other data than those in the chroot can be accessed.
53 Remember the starting point of the discussion: The statement "rsyncd uses
54 chroot, so an attacker can do nothing bad" is just false.