Message-ID: <e7d8f83e0711162357k8e06c0dqedaf0abd6c67e3fe@mail.gmail.com>
Date:	Sat, 17 Nov 2007 17:57:32 +1000
From:	"Peter Dolding" <oiaohm@...il.com>
To:	"Crispin Cowan" <crispin@...spincowan.com>
Cc:	rmeijer@...all.nl, apparmor-dev@...ge.novell.com,
	"LSM ML" <linux-security-module@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Arjan van de Ven" <arjan@...radead.org>
Subject: Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

On Nov 17, 2007 11:08 AM, Crispin Cowan <crispin@...spincowan.com> wrote:
> Peter Dolding wrote:
> >>> What is left unspecified here is 'how' a child 'with its own profile' is
> >>> confined here. Are it is confined to just its own profile, it may that
> >>> the "complicit process" communication may need to be wider specified to
> >>> include this.
> >>>
> > Sorry have to bring this up.  cgroups why not?
> Because I can't find any documentation for cgroups? :)
>
> >   Assign application to
> > a cgroup that contains there filesystem access permissions.   Done
> > right this could even be stacked.  Only give less access to
> > application unless LSM particularly overrides.
> >
> This comes no where close to AppArmor's functionality:
>
>     * Can't do learning mode
>     * Can't do wildcards
>     * Sucks up huge loads of memory to do that much FS mounting (imagine
>       thousands of bind mounts)
>     * I'm not sure, but I don't think you can do file granularity, only
>       directories
>
Ok sorry to say so far almost percent wrong.  Please note netlabels
falls into a control group.  All function of Apparmor is doable bar
exactly learning mode.   For learning mode that would have to be a
hook back to a LSM I would expect.

Done right should suck up no more memory than current apparmor.  But
it will required all LSM's doing file access to come to common
agreement how to do it.  Not just hooks into the kernel system any
more.

At the container entrance point there needs file granularity applied
for complete and correct container isolation to be done.
>
> > There are reasons why I keep on bring containers up it changes the
> > model.  Yes I know coming to a common agreement in these sections will
> > not be simple.   But at some point it has to be done.
> >
> Containers and access controls provide related but different functions.
> Stop trying to force containers to be an access control system, it does
> not fit well at all.
>
> Rather, we need to ensure that LSM and containers play well together.
> What you proposed in the past was to have an LSM module per container,
> but I find that absurdly complex: if you want that, then use a real VMM
> like Xen or something. Containers are mostly used for massive virtual
> domain hosting, and what you want there is as much sharing as possible
> while maintaining isolation. so why would you corrupt that with separate
> LSM modules per container?

Please stop being foolish.  Xen and the like don't share memory.   You
are basically saying blow out memory usage just because someone wants
to use a different LSM.

Besides file access control is part of running containers isolated in
the first place and need to be LSM neutral.

This is the problem current model just will not work.  Some features
are need in Linux kernel all the time and have to become LSM neutral
due to the features of containers.

Next big after filesystem most likely will be the common security
controls for devices.  These are just features need to complete
containers.  Basically to do containers LSM have to be cut up.  Or
containers function will be dependent on the current LSM to be use
completely.

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

Powered by blists - more mailing lists