Re: RFC: jail functionality

From: Colin Walters (walters@private)
Date: Thu Jun 30 2005 - 06:19:34 PDT


On Wed, 2005-06-29 at 13:42 -0500, serue@private wrote:
> Quoting James Morris (jmorris@private):
> > On Wed, 29 Jun 2005, Stephen Smalley wrote:
> > 
> > > > The attached task-lookup patches?
> > > 
> > > Not sure it provides much value.
> > 
> > If yoy need this, why not look at proper isolation via Xen?
> 
> Xen may be overkill for some cases, as you need (almost) a whole OS
> for each jail.  Zones and bsd jails (I believe) should easily be
> able to run hundreds of jails - provided of course they don't all
> peak at once.

What you are saying is: Xen is a heavyweight virtualization solution
that doesn't scale well when the user wants many instances of the exact
same OS, as opposed to potentially different OSes.

However, solving this (or at least drastically reducing the overhead) is
on the Xen roadmap:

http://www.cl.cam.ac.uk/Research/SRG/netos/xen/roadmap.html

(Shared buffer-cache and VM 'forks')

> And jails require some amount of access control.  I don't want to
> introduce a new LSM for this, but just put together the various
> existing (and not-yet-existing) pieces into an easy to use package.

I think this is useful, actually.  For some uses like build system
chroots, all the user really wants is some integrity protection against
accidental damage from poorly-written code, they don't need resource
management or any strong guarantees of integrity in the face of
malicious code.  

But you should be aware that for a lot of the zone use cases, resource
management is very important, and SELinux doesn't provide that.  You
mention CKRM, but that's a whole other kernel patch.  Xen definitely
seems to be the approach that's winning here.






This archive was generated by hypermail 2.1.3 : Thu Jun 30 2005 - 06:21:30 PDT