Hey folks,
I have a question about chrooting daemons. I've been playing with this a bit lately but am unclear
as to just how much security it really provides. I know it restricts what files a service will
have access to while running (though properly set perms will do that anyway), but I also know that
some exploits can crash a service and drop it to a shell. If that shell is chrooted then great,
the would-be cracker has been severley limited in the damage that he/she can do. But it seems that
that would not be the case. 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? =:)
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. I know, chrooted sshd might sound silly but I actually
have a plan for it... if the amount of security it affords would be worthwhile.
I guess the short version of this is: exactly what kinds of attacks would a chrooted daemon help
minimize the damage of and what kind of attacks would it do little/nothing about? Opinions?
--Brad
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:20:25 EDT