Re: [gentoo-hardened] to chroot or not to chroot

[RB]

On Tue, Jun 9, 2009 at 14:44, Jan Klod<janklodvan@×××××.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.