The filehandles of the child die with the child. Whatever sockets the
exploited daemon had open will remain open until closed or the process is
ended.
If the daemon has a filehandle open to a file or directory *outside* of the
chroot, the exploit can potentially do malicious things.
As long as the daemon itself has dropped its root privileges and is run inside
a chrooted jail without setuid root binaries or access to critical
filesystems (like /proc or /dev) it is theoretically impossible for an
exploit to break out of that jail.
We run our User Mode Linux (UML) images in SKAS mode chrooted inside a jail.
The idea is that anyone able to break out of the UML virtual machine process
will still be unable to cause havok with other images on that same server.
The benefit of this is that we can install one service per UML without the
need to chroot them and maintain that jail - as the UML itself is chrooted.
- Ian
On Tuesday 24 June 2003 11:40, Jim Wildman wrote:
> 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.
-- - Ian C. Blenke <icblenke@nks.net>(This message bound by the following: http://www.nks.net/email_disclaimer.html)
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:21:03 EDT