Date: Fri, 25 Dec 1998 10:00:33 +1030 (CST) From: Mark Newton <newton@atdot.dotat.org> To: robert+freebsd@cyrus.watson.org Cc: newton@camtech.com.au, eivind@yes.no, casper@acc.am, freebsd-security@FreeBSD.ORG Subject: Re: About chroot Message-ID: <199812242330.KAA00819@atdot.dotat.org> In-Reply-To: <Pine.BSF.3.96.981224111259.398A-100000@fledge.watson.org> from "Robert Watson" at Dec 24, 98 11:19:04 am
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote:
> On Thu, 24 Dec 1998, Mark Newton wrote:
> > I've submitted the patch; It's kern/9183.
> >
> > Does anyone want to review it? I'll commit it if there's a positive
> > response (but won't if there's no response).
>
> Mark,
> It seems like a neat idea. However, enabling vfs.hard_chroot may break
> security in certain environments--in particular, environments where a
> chroot is used as part of the system bootup, and where existing services
> will try to use chroot to create sandboxes.
Agreed. I figured those cases would make up a minority.
(re: booting off a floppy) Don't people boot off CD's these days? :-)
> I think a larger nastier warning note in the documentation would probably
> be sufficient. Something specifically mentioning chroot web servers,
> anonymous ftp, etc.
Yup. They're the cases it's intended to address: Web servers, ftpd,
pesky users who are put in jails by their login shell, etc.
> Needless to say, also, this patch only provides limited protection against
> chroot escape attempts. It prevents the user from chrooting to trick
> userland utilities that rely on hard-coded paths (such as access to ld.so,
> libc for getpwnam, etc). This is useful, but doesn't prevent a root user
> inside the sandbox from creating device nodes, mounting file systems, etc.
> And with that kind of capability, chroot won't do much. :-)
Of course -- But that's relatively easy: The same check for
p_rdir that's used to work out whether chroot() should fail can also
be placed into mknod(2) and mount(2). I wouldn't even need to
unstaticize hard_chroot to make those changes happen.
If it gets more widely used, though, the p_rdir check probably should
be wrapped in a function that can be called from elsewhere in the kernel
to do a permission check -- if hard_chrooted() returns TRUE, fail the
operation...
We'd probably also want to restrict a user's ability to access LKM/KLD
interfaces, assuming they're in the kernel in the first place. reboot(2)
should also be restricted. Are there any others? (deny bind()ing to
privileged ports? nah, that'd break ftpd, which is part of the
intended audience of the patch, with very few security benefits).
If we commit something like this it might be worth creating a new
hard_chroot(7) manpage and referring to that out of chroot(2),
mount(2), mknod(2) and any other manpages that are affected by the
change. hard_chroot(7) could contain a detailed description of what
the patch does and the effects it is likely to have on the types of
services you mentioned above as things this patch is likely to
break, as well as descriptions of what it can help with.
- mark
--------------------------------------------------------------------
I tried an internal modem, newton@atdot.dotat.org
but it hurt when I walked. Mark Newton
----- Voice: +61-4-1958-3414 ------------- Fax: +61-8-83034403 -----
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812242330.KAA00819>