Date: Thu, 7 Jan 1999 02:01:41 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Mark Newton <newton@atdot.dotat.org>, 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: <199901071001.CAA03365@salsa.gv.tsc.tdk.com> In-Reply-To: Mark Newton <newton@atdot.dotat.org> "Re: About chroot" (Dec 25, 10:00am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 25, 10:00am, Mark Newton wrote: } Subject: Re: About chroot } 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. There's at least one place where I need two levels of chroot(). The hack that I'm currently using added another rdir-like entry to struct filedesc. I'm currently in the process of reimplementing this as a stack. The main main problem I'm having is a lack of time to work on the code. One tricky thing is that once you allow more than one level of chroot(), you create the possibility of breaking out of the jail. I've got some ideas on how to protect against this. } 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. I did something like this a couple years ago (don't forget about umount()). My current preference would be to set a flag in struct proc that disables access to these. The process that puts the suspect process in jail would do the chroot() and set the flag. Even better would be finer grained access control. It's too bad that POSIX wasn't able to standardize something. } 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). I disabled access to lkms, blocked access to processes outside the jail by kill() and ptrace(). } 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. 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?199901071001.CAA03365>