Date: Wed, 17 May 2000 12:41:49 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: "Jacques A . Vidrine" <n@nectar.com> Cc: Geoffrey Robinson <geoff@grobin.org>, security@freebsd.org Subject: Re: Jail: Problems? Proper Usage? Status? Practicality? Message-ID: <Pine.NEB.3.96L.1000517123129.20229D-100000@fledge.watson.org> In-Reply-To: <20000517110758.C6884@bone.nectar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 May 2000, Jacques A . Vidrine wrote:
> On Wed, May 17, 2000 at 11:05:07AM -0400, Robert Watson wrote:
> > Jail works by:
> >
> > 1) Chrooting the child process
> > 2) Limiting the scope of superuser privileges accessible by uid0 processes
> > in the jail
> 3) Limiting network access to a single IP address
>
> [snip]
> > Right now, each jail costs you the size of
> > world, and is hard to upgrade if you have any decent number of jails.
>
> You don't need the whole world depending on what you are doing. If a
> jail is setup for the purposes of a single application (which I expect
> is the most common scenario), you only need the files that support it.
I had a script that built a much-reduced world necessary for a simple
virtual server environment. As you suggest, it's possible to throw out
almost all of /sbin, substantial parts of {/bin,/usr/bin,/usr/sbin}, all
of /boot, /kernel, and so on. Many of these utilities are used for
managing hardware, the boot process, etc, and are not relevant in a
restricted jail environment. Sadly, my concise list of files got toasted
with a lost notebook hard disk, and I haven't had a chance to reproduce it
yet. I probably will at some point. Even so, by the time you've thrown
in a substantial /usr/lib and so on, you still have a decent sized chunk
that is identical across all jails. A working read-only nullfs would
substantially improve this problem.
It also improves the backup situation: I can require (and enforce) that
all jail-specific data be stored in {/etc,/local/,var} off of the jail
root, and not worry that by upgrading /usr I'm going to wipe out local
files, and know that my backups catch everything.
> Upgrading the jail is simple if you created a script to create the jail
> in the first place -- you re-run the script after upgrading the base
> system.
Simple, but costly. Imagine for a moment that you have 700 jails on a
single machine, and you'd like to be able to consistently announce to all
admins of all jails that a version upgrade is taking place on 5/16/2000,
and the downtime is one hour :-). I'd rather have a single file system
exported to all jails, saving space and time.
> For me the real problem with this scheme is producing the script for
> building a jail in the first place. I do it by hand. One of these days
> I'd like to try writing an application that can generate a first-draft
> script for building a jail, given a list of applications that need to
> run in the jail. I think it might be nifty to do this based on the
> output of a ktrace on the target applications during a test run.
I didn't have mine tuned quite that much, I just eliminated clearly
unnecessary things (dmesg, ipfw, ifconfig, ...). Clearly what you
eliminate depends a lot on what you want to do with the jail. You might
consider using some combination of nm and strings to pull out
dependencies, also. I had a tool at one point that caught all read and
write references to files during the boot process, which I was using to
determine appropriate file settings for securelevel. A similar idea for
jails would be a possibility, although that only catches the files that
were used, not the files that might be used :-).
> > 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).
>
> I don't think you want this unless the purpose of your jail is to
> provide a `complete virtual server' for shell access et. al. I don't
> want e.g. `cc' or `sync' or most of the things in `/dev' to be available
> to a jailed process.
The majority of /dev is already not available, or there would be security
problems. :-)
Again, I agree -- it's possible to substantially trim. However, in the
environment I'm looking at, 30mb per-jail wasted is a lot of waste. With
700 jails, that's 2.1gb of wasted space (which needs to be RAID for the
jails to be reliable), and also 2.1gb of copied files for each upgrade,
opening a substantial time window for problems to occur. I'd like to be
able to (effectively) atomically upgrade a jail by shutting down the jail,
umounting its /usr reference, mounting the new /usr reference, and
restarting the jail.
Needless to say, this would require two jail /usr partitions, one that was
to be moved in, one that would contain the old one while the move was in
progress.
> > I'll gather up my notes on possible improvements and post them to
> > -security sometime in the next week or two. Thanks!
>
> Yay, thanks Robert!
Robert N M Watson
robert@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
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.NEB.3.96L.1000517123129.20229D-100000>