> On Fri, 2002-07-05 at 10:02, Miquel van Smoorenburg wrote:
> > In article <1025877004.11004.59.camel@zaphod>,
> > Shaya Potter <spotter@cs.columbia.edu> wrote:
> > > I'm trying to develop a way to ensure that one can't break out of a
> > > chroot() jail, even as root. I'm willing to change the way the
[snip]
> > Run as root and you're out of the chroot jail. This is because
> > chroot() doesn't chdir() to the new root, so after a chroot() in
> > the chroot jail you're suddenly out of it.
> yes, that's what the man page says. Is that the only hole? i.e. if one
> changed the semantics of chroot() to also do a chdir() to the new root,
> would that be fixed? (not arguing on changing this for everything, just
> for something specific)
No, there are many ways that root can break out of chroot(2). I maintain
some patches[1] against 2.2 (and grsecurity[2] has ported most of them to
2.4) which aim to try to make it harder for root to break out of chroot(2),
but I won't say I've got them all--in fact I'll say I'm sure I *don't* have
them all, and I'd like to hear suggestions for more. Here are some things
to worry about:
-chroot(2)'ing with an open directory fd
-prevent chroot(2) by a process already chrooted ("double-chroot")
-block mount(2) attempts inside chroot ("chroot(../..)" ...)
-block mknod of char or block devices inside chroot ("mknod /dev/hda",
"mknod /dev/kmem")
-block chmod +s by a chrooted process
-block ptrace(2) by a chrooted process of processes outside the jail
-block most signals by a chrooted process to processes outside the jail
-block setting capabilities (capset) by a chrooted process of processes
outside the jail
-drop "dangerous" capabilities when chroot(2)'ing. (See the patch, but
basically, various *_ADMIN, *RAW*, etc to block ioctl, sysctl for
dangerous things.)
One area I have not looked at sufficiently is sysv IPC (shared memory,
semaphores...). It's quite possible that a chrooted process can tamper
with shared memory segments that other, outside-chroot processes are using
(especially if some app is designed to use them to communicate across the
chroot boundary; I don't know of any but they could exist) and use that
vector to attack and try to subvert the other, non-chrooted process(es).
I'd appreciate any suggestions in addition to the above, and/or holes poked
in the implementation (which I'm sure isn't the best...).
[1] http://www.theaimsgroup.com/~hlein/hap-linux/
[2] http://www.grsecurity.org/
Thanks,
-- Hank Leininger <hlein@progressive-comp.com> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/