Re: [SLUG] Just how much security does chroot'ing services give you? Real world examples?

From: Jim Wildman (jim@rossberry.com)
Date: Tue Jun 24 2003 - 11:40:11 EDT


If the daemon truly dies, you are left with nothing. If you've managed
to run some exploit to leave a stub there, it only has access to the
chroot environment. Once that stub exits, you are left with nothing.
A process started with init in a chroot jail has no context to
return to.

If there is anything more, then it there is a problem with the chroot
code.

------------------------------------------------------------------------
Jim Wildman, CISSP, RHCE jim@rossberry.com
http://www.rossberry.com

On Tue, 24 Jun 2003, Andrew M Hoerter wrote:

>
> BTW: you may wish to fix your line-wrapping. Your message extends beyond
> 80 columns with no breaks, which makes replying to your message on many
> UNIX-based mailers faintly annoying. Just a suggestion.
>
> On Tue, 24 Jun 2003, Brad Smith wrote:
>
> > I've been playing with this a bit lately but am unclear as to just how
> > much security it really provides.
>
> It's a damage compartmentalization technique. Just like the Titanic had
> separate watertight compartments to contain hull breaches, chrooting
> services limits the damage done by compromising those services.
>
> If somebody compromises my chrooted apache instance, they only gain access
> to whatever is in that chroot "jail". Sure, maybe they can delete the
> documents I was serving, but the damage is well-contained and I can be
> reasonably certain that the rest of my system is intact.
>
> > I know it restricts what files a service will have access to while
> > running (though properly set perms will do that anyway),
>
> Properly set permissions don't protect against access by root. Most
> services you would desire to protect by chroot()ing them run as root.
>
> > but I also know that some exploits can crash a service and drop it to a
> > shell.
>
> Not exactly... the exploits usually contain a small bit of code that
> executes a shell and binds it to a particular port, so the attacker can
> make use of the victim host.
>
> > If the daemon is run chroot, then when the daemon dies, the chroot-ness
> > would seem to go with it. If the daemon were run from a chrooted bash,
> > then the cracker would be dropped to the chrooted shell but what is to
> > stop them from just typing 'exit' and being dropped back to the
> > un-chrooted shell that the service was spawned from? If the service was
> > spawned directly from init, would there be nothing to drop back to? What
> > if I manually restart the service later? Am I making sense? =:)
>
> Not really. UNIX just doesn't work this way. You don't "drop to a
> shell" in the way that's being suggested. I guess I can understand how
> you might get this impression running things interactively via the shell,
> but the shell itself is what orchestrates all that stuff. The parent
> process of most daemons is init, anyway.
>
> > I'm interested in hearing the experiences of people who have done this in
> > a real-world context and what they feel they've gained from it. Named is
> > trivially easy to chroot under RedHat, but I've almost got sshd beaten
> > into submission.
>
> OpenBSD chroots named and apache as well. OpenSSH uses what's called
> privilege separation, which has similar goals to chrooting but isn't quite
> the same thing. Operations inside of OpenSSH that require root privilege
> are isolated into a separate process, which communicates with the non-root
> process to divide their labor as appropriate. This separate process is
> small, easily audited, and particularly hardened against compromise. If
> its security were broken, however, that would be Bad.
>
> There are patches out there to chroot particular users logging in via SSH.
> Maybe you should take a look at those.
>



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:20:55 EDT