Date: Mon, 11 Jan 1999 17:29:08 +1030 (CST) From: Mark Newton <newton@atdot.dotat.org> To: robert+freebsd@cyrus.watson.org Cc: 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: <199901110659.RAA19654@atdot.dotat.org> In-Reply-To: <Pine.BSF.3.96.990110234033.11143D-100000@fledge.watson.org> from "Robert Watson" at Jan 10, 99 11:52:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote:
> 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 :).
Ah, that's different from the design goals of hard_chroot <grin>
All I'm trying to achieve is a hardening of the concept of chroot()
which will suit the majority of cases people use it for *at present*
(i.e.: anonymous ftpd, httpd, jails for shells, etc).
Nested sandboxing will no doubt open up whole new vistas of applications
that hard_chroot is ill-suited for, but they're kinda not quite here
yet :-) In the meantime, I know quite a few people who don't need
nested sandboxing who have itches in hard to reach places as nervous
reactions against chroot().
> 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.
> > > 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? :-) ]
> > 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.
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).
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? :-)
In the meantime, are we going to do anything about chroot() ?
- 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?199901110659.RAA19654>