Date: Mon, 11 Jan 1999 10:16:47 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Mark Newton <newton@atdot.dotat.org> Cc: Don.Lewis@tsc.tdk.com, newton@camtech.com.au, eivind@yes.no, casper@acc.am, freebsd-security@FreeBSD.ORG, terry@lambert.org Subject: Re: About chroot Message-ID: <Pine.BSF.3.96.990111100041.11143I-100000@fledge.watson.org> In-Reply-To: <199901110659.RAA19654@atdot.dotat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Jan 1999, Mark Newton wrote: > > 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. > > That's a degenerate case: The chroot happens before init starts, so > all non-jailed processes running off the CD-ROM or MFS will have > the same fd_rdir as init unless they're specifically chroot()ed, hence > they'll be unrestricted by vfs.hard_chroot unless you actually invest > effort in restricting them. For common use today, that is a degenerate case. But in the event of more sophisticated network file systems (such as AFS, Coda, Samba, etc) in the boot process, it might be desirable for userland daemons to support the file system later used as /. For example, Coda and AFS both require a userland process that acts as a cache manager. The cache manager attaches to a device in /dev and uses it for up/downcalls from the kernel. When the kernel sees a reference to a section of the file system maintained by the cache manager, it will proxy some of the request to the userland process so that files can be transfered from file servers, and user interaction can occur in the event of failure or a requirement for authentication, etc. But for all this to work, you have to have a userland process running that also has access to space on disk to have a file cache and, in Coda's case, log space for disconnected operation. I can see the case where after boot, you would want / to be in AFS or Coda for reasons of scalability and management (not to mention consistency from the user's point of view--having one kind of ACL everywhere makes a lot of sense). The easiest way to do that might be to have a multi-phase boot, in which first the kernel loads up off a local file system, runs the cache manager via the rc scripts from init, and when all is ready, something (rc or init or someone) chroots before continuing on to the rest of the interesting boot stuff. This would probably require a more structured rc sequence, possibly with runlevels, etc, but seems like a useful goal. > > > > 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. > > Terry doesn't have a reference? > > [ or an alias? :-) ] I don't know--Terry, do you have a reference? :) I've been searching, and someone finally pointed me at a site for discussing IEEE computer science drafts, but it requires a subscription, and it wasn't even clear to me that the draft would be available there if I did have a subscription. If anyone knows for sure where it is, I'll get a subscription, but I'm reluctant to shell out without knowing more about what I'm getting. I'll do more research this week and see what I can dig up (the reference librarian's at CMU's library were, unfortunately, not very useful :-). > You could do that if your restricted environment manager wasn't running > in a jail (remember, FAIL_HARD_CHROOT(x) only fails if x is true *AND* > the process calling it is in a jail (*AND* vfs.hard_chroot is nonzero) > -- Hence normal process killing semantics apply for unjailed processes, > including the ability for an unjailed process to kill a jailed one). > > A jailed process can kill any other process which is in the same > jail. An unjailed process can kill anyone as per the original semantics > of kill(2). sounds great :). That is what I had hoped for, but misinterpretted as not being there. > It sounds like what you really want is machine partitioning. IRIX 6.5 > does this as a hardware/software bundle on ORIGIN architectures (allowing > you to set up partitions on ORIGIN module boundries), but I don't think > FreeBSD is quite in that league yet. > > Know any grad students looking for a project? :-) Sounds like a great project, but quite time consuming. I don't think I have the time :-). I don't have enough time for my own projects, let alone any new ones... Some of the Sun servers can do this also, always seemed like a great idea, albeit a complicated one. I suspect that rather than hacking this support into FreeBSD, you'd want to base it on something else and stick a BSD syscall interface on top, and a POSIX library set. > In the meantime, are we going to do anything about chroot() ? It looks spiffy, but I'd want to try it out for a while before anyone put it in. Want to put together a tarball of the patches, and a couple of sample programs that demonstrate the effectiveness of the chroot environment, as well as the signal behavior, etc? :) That way I can drop it in and play with it on a machine. 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.990111100041.11143I-100000>