jankeso at gmail
Jun 9, 2009, 10:58 PM
Post #2 of 17
(3687 views)
Permalink
|
Hi,
I'm no expert but since you ask for opinions, here are some of mine :)
(Please, anyone, correct me, where I'm wrong.)
> 2) suppose I chroot Apache: what chances it still has to harm something in the
> outside OS? My knowledge about various system capabilities, network etc is
> too little, so enlighten me... And how big is an Apache chroot?
Starting with the last question - this, to my knowledge, seems to be
irrelevant. Chrooting (at least the simple cases I know and use) does
not require any additional or dedicated disk space. It is, in its
basic nature, an operation of changing the environment so that it
seems as if some chosen path (say /usr/chroot) was actually the root
(/) path. And as such, it is visible to all the programs run in this
env.
I'm not sure I understand the first part of the question - do you
mean, "what chances" of:
1) the chroot itself harming your OS,
2) you harming your OS by possible administrative mistakes - chroot confusions,
or
3) a potential attacker harming your OS after having compromised the Apache?
All of these are _some_ threats. If I were to try and order them
according to probabilities of mishaps, it'd be 2-1-3. That's assuming
you know not-too-much of how the system is structured. But it all
depends on really many, many, (...) things. For instance, if you just
hang on to some tutorial, then any of the first two is the more
possible, the more you decide to do your own way. But generally, I'd
bet the first is far less probable than 2, while both are quite
unlikely once you understand the idea of chroot and be careful to keep
it in mind at all times.
Still, I must say I know no details of "typical" Apache chroot
scenarios. As far,as I can imagine, there shouldn't be a place for
many tricky parts of it. But I'd be pleased to hear someone more
experienced in these matters.
The no. 3 is probably by far the least probable, as, firstly - the
chance of a random, small, non-production http server on the web being
attacked is very little. That is, the_http_server_itself. I believe it
is a few times more likely for a _box_ being attacked in other ways,
just because it showed itself to the web (running a http server),
rather than the http server itself being targeted against. And
secondly, once the Apache server is chrooted, the probability of the
system being harmed in _direct_ consequence of the fact that http got
compromised is greatly lessened thanks to chroot. Mind the "direct"
though, as it refers to the previous comment.
>
> And by the way, how big are the risks for sshd and ntpd to open up a way into
> the hardened gentoo system? Can that recent ntp glsa be ignored, if its
> hardened with memory protections?
At this point, again, I have to admit my ignorance, as I don't know in
what ways sshd, ntpd or any-d at all is actually hardened in h-g. Yet
I can just bet, that no matter how brilliant ideas of the h-g team are
brought into effect, potential ssh access being the most looked for by
the attackers, will be the one that, once gained, would pose the
greatest threat to the system. (NOW I get to be yelled at ;D)
I'm not saying it is easy to break into - certainly, in its
architecture, it isn't! I just mean that, in its nature, it can expose
the weakest points of your configuration and provide the most
convenient way of accessing the box, once compromised. Just keep this
in mind.
Ok, as I probably have made a fool (and ignorant) of myself anyway by
now, I'll add just one more stupid sentence: I haven't read the glsa
you refer to, but I would bet there would be many easier ways for an
attacker to get into a newly-and-n00bly setup server than compromising
ntpd.
Done. Now I get the laughs, please...
|
