Date: Wed, 17 May 2000 18:51:04 -0400 (EDT) From: Geoffrey Robinson <geoff@grobin.org> To: Robert Watson <rwatson@freebsd.org> Cc: security@freebsd.org Subject: Re: Jail: Problems? Proper Usage? Status? Practicality? Message-ID: <Pine.BSF.4.10.10005171842470.81906-100000@grobin.org> In-Reply-To: <Pine.NEB.3.96L.1000516170812.15891F-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 May 2000, Robert Watson wrote:
> > If a process running in the host system created a UNIX domain socket or
> > named pipe within the jail directory tree. Would a process running in the
> > jail be able to connect to and communicate with the host process through
> > this socket or pipe? If so I guess you could create work around for just
> > about anything by running it on the host system. Would this create a
> > potential way of defeating the jail?
>
> Jail works by:
>
> 1) Chrooting the child process
> 2) Limiting the scope of superuser privileges accessible by uid0 processes
> in the jail
>
> It does not attempt to prevent processes outside the jail from
> communicating with processes within the jail. As such, having a process
> do so wouldn't defeat the jail per se, but would defeat the purpose of the
> jail :-).
Still, like any network service the security impact would depend on how
well the server application was written not on the fact you have a link to
the host system. Right?
> I'm not clear on why that would happen -- the libc (etc, etc) in each jail
> should be kept in synch with the kernel, however, and that could be source
> of your problems. I.e., if you upgrade the kernel, it exports the same
> syscall interface to all processes, regardless of jails, so all jails
> making use of syscalls that have changed need to be upgraded in synch.
>
> This is the same as upgrading the kernel without upgrading your normal
> world.
>
> One way to substantially improve jail scalability would be to allow the
> same (read-only) file system to be present in all jails as the root, with
> only jail-local data being modified. You can imagine gratuitously using
> nullfs (if it worked) to do this, and mount per-jail writable fs's for
> appropriatel subdirectories (/etc, /usr/local, /home) with appropriate
> symlinks within the jail. Right now, each jail costs you the size of
> world, and is hard to upgrade if you have any decent number of jails.
> Storing all that stuff in a single tree mapped read-only into jails would
> solve that (you'd probably want two so you could upgrade one, test it, and
> then swap to that for all jails so as to minimize downtime).
If I wanted to do that. Would it be as easy as building a jail on a
spare partition then mounting it read-only to the correct locations?
------------------------------------------------------------------------------
| Geoffrey Robinson - geoff@grobin.org |
------------------------------------------------------------------------------
Random Fortune Quote
"What's another word for Thesaurus?"
-- Steven Wright
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.4.10.10005171842470.81906-100000>