Re: [patch 2/3] lsm: add bsdjail module

Herbert Poetzl
2004-10-20T19:25:19Z

On Wed, Oct 20, 2004 at 04:36:21PM +0100, Christoph Hellwig wrote:
> On Tue, Oct 12, 2004 at 02:27:33PM +0200, Herbert Poetzl wrote:
> > On Tue, Oct 12, 2004 at 10:00:57AM +0100, Christoph Hellwig wrote:
> > > On Tue, Oct 12, 2004 at 09:00:55AM +0200, Herbert Poetzl wrote:
> > > > and it works well, because we use it for almost
> > > > a year now on linux-vserver ;)
> > >
> > > Btw, could anyone explain the exact differences between linux-vserver
> > > and this jail module?
> >
> > hmm, okay I'll try ...
> >
> > linux-vserver is a combination of kernel patch and
> > userspace tools to create 'virtual servers' similar
> > to UML, but sharing the resources (and kernel).
> >
> > to do this, it uses process isolation, network
> > isolation and disk space separation (tagging).
> > in addition it does resource management (accounting
> > and limits) for various aspects (CPU, memory,
> > processes, sockets, filehandles, ...)
> >
> > the jail module is recreating a limited subset of
> > the isolation aspect via LSM (similar to the BSD
> > jail) which allows to confine a process (and it's
> > children) to a chroot() environment under certain
> > limitations (resources)
>
> So why
>
> a) can't linux-vserver use LSM hooks where applicable

well, it could, and probably in future it will do so,
but currently there are three reasons which keep me
from doing that:

1) some folks want to use LSM for other things, and
proper stackering of LSM was broken/missing last
time I looked at the code

2) performance: I'm not convinced that the LSM
hooks are a good choice, where a single check
of a flag (in current) is more than sufficient

3) why move 20% of linux vserver to LSM, where
those 20% can not do anything useful without the
remaining 80% (or at least some part of it)
which can not be done with LSM for various
reasons.

> b) can't the two projects share code so we don't only have a crippled
> version in mainline

I'm sure the projects can share code, and IMHO the
best solution would be to create a 'cripled' version
of linux-vserver and to include it in mainline (if
that is what kernel folks want) and to slowly extend
this version where possible, moving existing code
from linux-vserver into mainline ...

once CKRM is working and included, and LSM provides
the 'security' features, linux-vserver might become
a simple compile time option ...

best,
Herbert

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/