On Tue, Jun 9, 2009 at 14:44, Jan Klod<janklod...@gmail.com> wrote: > 1) how big are possible risks of hardened gentoo system compromise, if apache > is run normally, therefore a need of chrooting?
Mildly less than that a non-hardened system. All the stack-smashing and memory protections in the world won't protect you against a poorly-configured system. A hardened system would reduce the probability of a remote Apache compromise, but does little to prevent damage once the compromise has been made. > 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? Less chance if you've turned on the hardened kernel's chroot() protections (see http://www.grsecurity.net/features.php for the list). In a nutshell, said restrictions address the known set of jailbreak tricks, helping keep a chroot() really a chroot(). There's still the [very] outside chance that a kernel 0-day or previously unknown jailbreak may pop up, but your attack surface is definitely lessened. Size is variable - basically, you need the binary that's going to run, all its libraries, and the on-disk data it will need to access (static pages, etc.). I'm seeing 2.7M taken up by my basic apache-2.2.11 install, of which ~2.1M is the actual binaries, modules, etc. Add in the ~3.8M of objects the apache2 binary links against, various bits of configuration, and you're looking at roughly 6M for an unoptimized chroot. Look at one of the many chroot() preparation tools available in portage (emerge -S chroot) for easy ways to set up clean chroot() environments without any missing libraries. > 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? The NTP GLSA was a very specific one, addressing users that had not only compiled net-misc/ntp against OpenSSL, but had also configured the non-default 'autokey' authentication mechanism. I've not examined this particular compromise further to see whether the hardened stack would protect against it, but it has before in similar situations. SSH always increases your risk, but large portions of that may be mitigated with ACLs, strong authentication, and restrictive configurations. The suggestions of virtual machines are good, but are much more heavyweight solutions, resulting in good separation at the expense of resources. Even so, they cannot protect against poor configuration (nothing does) and may add complexity you're not willing to engage. SELinux (rather, a mandatory access control or MAC) is another option, but more augments chroot or virtualization mechanisms rather than replaces them. If you choose to pursue this route, I highly suggest at least looking at the grsecurity RBAC that is built into (and supported in) the hardened-sources kernel.
