Date: Sun, 10 Jan 1999 23:52:39 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Mark Newton <newton@atdot.dotat.org> Cc: Don Lewis <Don.Lewis@tsc.tdk.com>, newton@camtech.com.au, eivind@yes.no, casper@acc.am, freebsd-security@FreeBSD.ORG Subject: Re: About chroot Message-ID: <Pine.BSF.3.96.990110234033.11143D-100000@fledge.watson.org> In-Reply-To: <199901110434.PAA16078@atdot.dotat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Jan 1999, Mark Newton wrote: > Although multiple recursive levels of chroot() are one of those things > that would be "nice to have", do you think the implementational > complexity of an in-kernel root directory stack are worth it considering > that people have been able to work around chroot() limitations for the > last 20 years or so? I'd really like to see truly nested sandboxing in a general sense :). The Java people summarily failed to manage it in their 1.2 security model; they have no concept of nested sandboxes. A great example of a nested sandbox would be netscape running as an application under an operating system (that is, in a sandbox preventing privileged access, etc), and then an applet running under netscape in a further restricted sandbox. Or active code running in an execution environment on an active network router, etc. However! This doesn't mean I think it belongs in UNIX. Nested chroot is clearly desirable--that is, I chroot at boot time to bump me from my CD-ROM / to an MFS-mounted / or something, but then ftpd or httpd makes use of chroot to restrict users to specific directories. Only the inner-most chroot needs to be 'hard' by your definition of hard, I think (or perhaps I have it backwards--I spent most of the day traveling :). > [ ooooh, I'm gonna get it in the neck for that question... ] Deep question, but FreeBSD in my view should not be an outlet for it. The whole syscall things and privileged processor stuff doesn't really make it appropriate. Mach and Trusted Mach were a nice thought but having a universal 'file system' with a universal 'name space' is really not going to fly, I think. So I think we should drop the question for now and raise it another day, and possibly another operating system. By appropriately writing userland libraries to allow 'services' mach-style, and not trying to have a syscall interface per se, you could have quite a spiffy nest sandbox. > > Even better would be finer grained access control. It's too bad that POSIX > > wasn't able to standardize something. > > <shrug> IRIX, HP-UX and Solaris have ACLs. I would have implemented this long ago in FreeBSD if I could just get the d*mn POSIX draft describing them. Someone find me a copy (fax it, email it, mail it, something -- I'll pay postage, shipping, etc) and I'll do it :-). That and POSIX capabilities. Not that either is ideal in my view (I prefer AFS-style directory ACLs myself, and I think that capabilities POSIX-style (as I understand them, not having seen the spec) are really just a gross hack). > Mind you, they also have filesystems which support multiple "forks" per > file to support them... Well, it depends how you do it. Someone's thesis at UCLA (I have a copy around here somewhere and will dig it up) involved using a multi-fork layered file system to add ACL support, but I wasn't impressed (they forgot to include a biobliography in the masters thesis). Terry also talks fairly frequently about ACLfs. I'm not convinced this is the long-term solution, although it would be great for an initial implementation if layering worked. If you really want ACLs, I suspect it should be built into the base file system, as they are designed as a suplement to permissions. Again, not having seen the spec, I can't judge how realistic that suggestion is. Without user-defined groups, ACLs are a real pain to manage. > > } 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(). > > On further reflection, the lkm (or kld) and ptrace cases are already > covered by kern.securelevel. > > The kill case could be covered by unstaticizing hard_chroot, putting > the FAIL_HARD_CHROOT() macro into a .h file, and putting something like > the following (untested code) at the front of kill()/killpg()/etc in > kern_sig.c: > > FAIL_HARD_CHROOT((pfind(uap->pid))->p_fd->fd_rdir != cp->p_fd->fd_rdir); > > i.e.: fail the kill() operation if the root directory of the target > is not the same as the root directory of the caller. This would > mean that processes in one jail couldn't kill processes in other > jails on the same system too. But I'd like my restricted environment manager to be able to kill processes running in the environment without actually being in it. And that harps back to the whole nested thing. I'm not convinced that chroot is really particularly compatible with such a hackish operating system as UNIX. Too much is based in the file system, and there are so many ways of doing everything, especially once you through in sysV shared memory, mmaping, device nodes, etc. What a pain securelevels are to do right, and they provide such basic functionality. So much is based on uid--one might do better to simply replace the underlying authorization system all over the place than try to hack in support. 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.990110234033.11143D-100000>