Date: Thu, 24 Dec 1998 11:19:04 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Mark Newton <newton@camtech.com.au> Cc: eivind@yes.no, casper@acc.am, freebsd-security@FreeBSD.ORG Subject: Re: About chroot Message-ID: <Pine.BSF.3.96.981224111259.398A-100000@fledge.watson.org> In-Reply-To: <199812240714.RAA17322@frenzy.ct>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Dec 1998, Mark Newton wrote: > > I have a patch which completely disables chroot() for processes which > > have already been chroot()'ed (by making chroot() fail with EPERM > > if the process' root directory is not the same as init's root directory > > whether it's being called by the superuser or not). > > 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. A prime example might be a netboot'd anonymous FTP server. For whatever reason, the boot device is not writable, or should not be writable during the normal system run; once the system gets up, it chroots so that the root directory is in a more convenient place than on the original boot media. Now, the ftp daemon will attempt to chroot to the ~ftp directory when a user logs in. chroot will now fail, preventing the creation of a sandbox. I suppose a better example might be booting off of a floppy disk once we have modules working properly--during the boot sequence, it is desirable to have access to the root directory to load modules from file systems. But after we're done with that, we will want to chroot to that mfs root directory for performance reasons. I think a larger nastier warning note in the documentation would probably be sufficient. Something specifically mentioning chroot web servers, anonymous ftp, 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. :-) Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ 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?Pine.BSF.3.96.981224111259.398A-100000>