1 |
Hi Vaeth, |
2 |
on Wed, Sep 17, 2008 at 10:40:47AM +0200, you wrote: |
3 |
> > > Alan Cox: "chroot is not and never has been a security tool", see e.g. |
4 |
> > > http://kerneltrap.org/Linux/Abusing_chroot |
5 |
> > |
6 |
> > No disrespect to Mr. Cox but a silly argument stays a silly argument |
7 |
> > even if brought forward by Alan. Programs like postfix certainly don't |
8 |
> > use chroots for security because they were designed noobs or incompetent |
9 |
> > people. |
10 |
> |
11 |
> I did not cite the webpage because of the insults but because it shows |
12 |
> how much the kernel programmers are interested in closing possible ways |
13 |
> to break out of a chroot |
14 |
as root |
15 |
> : not at all, because they think it is ok. |
16 |
> That's why I said that _only_ with grsecurity a chroot _might perhaps_ |
17 |
> be considered as a serious security measurement (but in fact, people |
18 |
> which really need chroot to run binaries from two systems cannot activate |
19 |
> these security enhancements). |
20 |
|
21 |
Sure, you can't expect that the Debian-loving friend you gave root on |
22 |
your Debian-chrooted-on-Gentoo system will stay confined to that chroot. |
23 |
Big deal, just don't do it. That's not what any sane person would |
24 |
recommend chroot for anyway. |
25 |
|
26 |
> > Alan acknowledges that "Normal users cannot use chroot() |
27 |
> > themselves so they can't use chroot to get back out" |
28 |
> |
29 |
> Yes, _this_ method of breaking out does not work without additional |
30 |
> exploits like privilege escalation. (grsecurity closes a lot more methods; |
31 |
> I did never reasearch which tricks might perhaps work as a user). |
32 |
> But if everything works as it should, just running with low privileges |
33 |
> does not make much of a difference than running with low privileges in |
34 |
> a chroot: In any case you should only have access to those data which |
35 |
> the privileges allow. |
36 |
|
37 |
...which is usually pretty much everything in the bin directories, a lot |
38 |
of stuff in /etc, and most importantly a shell. In a non-chrooted |
39 |
program, an attacker who can exploit a bug can simply bind /bin/sh to a |
40 |
port, run netcat, even use your compiler to prepare the next steps for |
41 |
perhaps a local privilege escalation. In a chroot, nothing of the sort |
42 |
is possible, you're limited to what you can do in your injected code. |
43 |
|
44 |
> (Admittedly there is a _slight_ increase in security: You might now be |
45 |
> safe of ways of privilege escalation by bugs in certain |
46 |
> SUID-programms). |
47 |
|
48 |
...plus safe from most information disclosure that would otherwise be |
49 |
possible. |
50 |
|
51 |
> > That's not to say that setting up a vserver for each of |
52 |
> > your programs exposed to the net wasn't *more* secure than a chroot |
53 |
> |
54 |
> That's a different topic, but a vserver might also even be more |
55 |
> dangerous than doing nothing, because it has to be implemented (of course) |
56 |
> with the highest available privileges, and so you have an additional |
57 |
> risk of bugs (i.e. possible exploits) of the vserver - and in such a |
58 |
> case the attacker has immediately the highest privileges. |
59 |
|
60 |
That's true, I just mentioned it because that's what Alan mentioned as |
61 |
the true security tool. |
62 |
|
63 |
> > but it's certainly a whole lot more secure if used |
64 |
> > properly than not doing it at all. |
65 |
> |
66 |
> ...as is the usage of NAT as a "security feature". |
67 |
> Of course, saying that using NAT or using chroot would not increase |
68 |
> security at all would be a lie. But it is better to emphasize the |
69 |
> dangers than to support the common misbelieve (as Alan alrady pointed |
70 |
> out) that by using it there is no risk that "closed" ports can come |
71 |
> through or that no other data than those in the chroot can be accessed. |
72 |
|
73 |
Alan would probably emphasize the dangers of a seat belt and say |
74 |
competent people used it only to keep their shopping bags from falling |
75 |
over and not as a security tool because if you don't use it the |
76 |
recommended way you can strangle yourself with it =^> |
77 |
|
78 |
> Remember the starting point of the discussion: The statement "rsyncd uses |
79 |
> chroot, so an attacker can do nothing bad" is just false. |
80 |
|
81 |
Except that statement wasn't Neil's. To quote it correctly: |
82 |
| In addition, the default rsyncd configuration with Gentoo uses a chroot |
83 |
| jail. So even if you do allow connections to your portage tree, they |
84 |
| won't be able to access anything else. |
85 |
|
86 |
To summarize: for an attacker to be able to compromise a chrooted |
87 |
rsyncd behind a NATting DSL router: |
88 |
a) your ISP has to have a router configuration b0rked beyond belief |
89 |
b) the attacker has to be aware of that and be able to distinguish |
90 |
between your traffic and that of several hundred others that will |
91 |
respond to his packets to 192.168.x.x |
92 |
c) your router has to have a serious security hole |
93 |
d) rsyncd has to be exploitable |
94 |
e) your kernel needs to have a local privilege escalation bug |
95 |
|
96 |
Now if that risk is worth the more complicated configuration using rsync |
97 |
over ssh, I'm really not sure...I think I'd rather spend the time on |
98 |
folding tin foil hats for the upcoming attack from Mars ;) |
99 |
|
100 |
cheers, |
101 |
Matthias |
102 |
-- |
103 |
I prefer encrypted and signed messages. KeyID: FAC37665 |
104 |
Fingerprint: 8C16 3F0A A6FC DF0D 19B0 8DEF 48D9 1700 FAC3 7665 |