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:40 EDT