Re: LSM and Containers (was: LSM conversion to static interface)

Re: LSM and Containers (was: LSM conversion to static interface)

[Serge E. Hallyn]

Quoting Crispin Cowan (crispin@crispincowan.com):
> Peter, I may be mistaken, but I think you are talking about an entirely
> different issue than the LSM static interface issue, so I've changed the
> subject.
> 
> Peter Dolding wrote:
> > You are all focusing on vendors.  I am thinking server farm or people
> > running many different distros side by side using containers.
> This right here is a challenging goal.
> 
> It completely surprises me that anyone would consider trying to run
> different distros in different containers.

It seems reasonable to me.

> It would especially surprise
> me if one tried to run different kernels in different containers.

That's not just unreasonable, it's impossible :)

> It is my understanding of containers that they are intended to be a
> *lightweight* virtualization technique, giving each container
> effectively a private copy of identical instances of the host OS.
> 
> If you want to rent out divergent distros, kernels, etc. then it seems
> to me that heavier virtualization like Xen, KVM, VMware, etc. are the
> right answer, rather than trying to force difficult kernel solutions
> into the container and LSM features into the kernel.

For different kernels, yes, but unless you pick two distros which
require incompatible kernel features (?) I don't see running, say,
gentoo, fedora, and ubuntu under different containers as a problem.

Perhaps the biggest reason not to do that, speaking practically, is that
you miss out on some of the ability to share /usr, /lib, etc readonly
among containers to save overall disk space.

> I call it "difficult" because you would have to build a great big switch
> into the LSM interface, so that each hook is dispatched to the LSM
> module being used by the current container. This will impose some
> complexity and overhead, making each hook slower. Worse,the semantics
> become painfully undefined if a syscall by one container touches an
> object owned by a different container; which LSM gets called to mediate
> the access?

At first my thought was this is worse than dealing with stacker.

But on the other hand, perhaps introducing some sort of 'personality' to
objects and subjects, where the personality decides which LSM is invoked
for access, can be done more optimally than one would think.  It would
probably require strict enforcement that two "things" with different
personalities can NOT mix, ever.

> What makes a *lot* more sense to me is for individual LSMs to try to
> "containerize" themselves. This is actually the AppArmor plan: we hope
> to eventually support having a private AppArmor policy per container.

Agreed, that had been my assumption.  That, and that the configuring
of LSM policies inside a container would simply be disabled if say
loading a suse container under a fedora host.

> Thus all of the containers on the physical machine will be running
> identical kernels, and all will use AppArmor, but each one can have a
> different AppArmor policy set, so that e.g. my private Apache process
> instance is confined in my container different than your Apache process
> is confined in your container.
> 
> I see no barrier to SELinux or SMACK or TOMOYO doing the same thing. But
> I see *big* barriers to trying to support multiple LSM modules in the
> kernel at the same time with each container using the LSM of its choice.

It's not as clear to me how SMACK (or the MLS/MCS portion of selinux)
would be handled.

-serge

Re: LSM and Containers

[Crispin Cowan]

Serge E. Hallyn wrote:
> Quoting Crispin Cowan (crispin@crispincowan.com):
>   
>> It is my understanding of containers that they are intended to be a
>> *lightweight* virtualization technique, giving each container
>> effectively a private copy of identical instances of the host OS.
>>
>> If you want to rent out divergent distros, kernels, etc. then it seems
>> to me that heavier virtualization like Xen, KVM, VMware, etc. are the
>> right answer, rather than trying to force difficult kernel solutions
>> into the container and LSM features into the kernel.
>>     
> For different kernels, yes, but unless you pick two distros which
> require incompatible kernel features (?) I don't see running, say,
> gentoo, fedora, and ubuntu under different containers as a problem.
>
> Perhaps the biggest reason not to do that, speaking practically, is that
> you miss out on some of the ability to share /usr, /lib, etc readonly
> among containers to save overall disk space.
>   
This is why it just doesn't seem very reasonable. People who want to do
that will just use KVM or Xen. People who want the efficiency of
lightweight containers, and have enough load pressure to care, can just
have one Fedora physical box with many containers all running Fedora,
and another openSUSE physical box with many containers all running openSUSE.

I can see how you *could* manage to run different distros in different
containers, but you would have to make many compromises. No sharing of
read-only disk as Serge said. You would have to pick one kernel, as no 2
distros I know of actually run the same kernel. You would have to pick
one set of device drivers, and one LSM. By the time you deal with all
this crap, just using KVM or Xen starts to look good :-)

>> I call it "difficult" because you would have to build a great big switch
>> into the LSM interface, so that each hook is dispatched to the LSM
>> module being used by the current container. This will impose some
>> complexity and overhead, making each hook slower. Worse,the semantics
>> become painfully undefined if a syscall by one container touches an
>> object owned by a different container; which LSM gets called to mediate
>> the access?
>>     
> At first my thought was this is worse than dealing with stacker.
>
> But on the other hand, perhaps introducing some sort of 'personality' to
> objects and subjects, where the personality decides which LSM is invoked
> for access, can be done more optimally than one would think.  It would
> probably require strict enforcement that two "things" with different
> personalities can NOT mix, ever.
>   
Yes, that's what you would have to do. But I basically don't think it is
a good idea; use full virtualization if you don't want to share kernel
features among your virtual guests.

>> What makes a *lot* more sense to me is for individual LSMs to try to
>> "containerize" themselves. This is actually the AppArmor plan: we hope
>> to eventually support having a private AppArmor policy per container.
>>     
> Agreed, that had been my assumption.  That, and that the configuring
> of LSM policies inside a container would simply be disabled if say
> loading a suse container under a fedora host.
>   
This is why running an openSUSE container under a Fedora host (or vice
versa) seems daft to me.

>> Thus all of the containers on the physical machine will be running
>> identical kernels, and all will use AppArmor, but each one can have a
>> different AppArmor policy set, so that e.g. my private Apache process
>> instance is confined in my container different than your Apache process
>> is confined in your container.
>>
>> I see no barrier to SELinux or SMACK or TOMOYO doing the same thing. But
>> I see *big* barriers to trying to support multiple LSM modules in the
>> kernel at the same time with each container using the LSM of its choice.
>>     
> It's not as clear to me how SMACK (or the MLS/MCS portion of selinux)
> would be handled.
>   
That actually seems easier to me. You may not need to do anything at all
to the MLS/MCS code. There is no actual "policy" in MLS, it is just a
single policy (label dominance) and all of your "policy" is expressed
through labeling. So what you do is make the container ID be part of the
label schema, and poof! none of the containers are permitted to touch
objects belonging to any others, because they cannot dominate each other.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
	       Itanium. Vista. GPLv3. Complexity at work

Re: LSM and Containers

[Peter Dolding]

Crispin Cowan wrote:
> Serge E. Hallyn wrote:
>   
>> Quoting Crispin Cowan (crispin@crispincowan.com):
>>   
>>     
>>> It is my understanding of containers that they are intended to be a
>>> *lightweight* virtualization technique, giving each container
>>> effectively a private copy of identical instances of the host OS.
>>>
>>> If you want to rent out divergent distros, kernels, etc. then it seems
>>> to me that heavier virtualization like Xen, KVM, VMware, etc. are the
>>> right answer, rather than trying to force difficult kernel solutions
>>> into the container and LSM features into the kernel.
>>>     
>>>       
>> For different kernels, yes, but unless you pick two distros which
>> require incompatible kernel features (?) I don't see running, say,
>> gentoo, fedora, and ubuntu under different containers as a problem.
>>
>> Perhaps the biggest reason not to do that, speaking practically, is that
>> you miss out on some of the ability to share /usr, /lib, etc readonly
>> among containers to save overall disk space.
>>   
>>     
> This is why it just doesn't seem very reasonable. People who want to do
> that will just use KVM or Xen. People who want the efficiency of
> lightweight containers, and have enough load pressure to care, can just
> have one Fedora physical box with many containers all running Fedora,
> and another openSUSE physical box with many containers all running openSUSE.
>
> I can see how you *could* manage to run different distros in different
> containers, but you would have to make many compromises. No sharing of
> read-only disk as Serge said. You would have to pick one kernel, as no 2
> distros I know of actually run the same kernel. You would have to pick
> one set of device drivers, and one LSM. By the time you deal with all
> this crap, just using KVM or Xen starts to look good :-)
>   
Sorry the reason for doing it is 1 set of driver.  In particular 
Opengl.   KVM, Xen, Lguest... All virtual machines cannot handle it 
effectively so you have one very high comprise.  Containers can.

Same with other devices some devices don't take well at all being 
wrapped up in KVM,  Xen and other systems.  Running the same kernel is 
not a issue to me.

Most distributions I have run with standard from kernel.org with there 
LSM.   Nothing else added to kernel.   So the different kernel is null 
and void.   If LSM are rebuild we will see distro kernels with support 
for a broad range of distro support.   You may have a distro that allows 
like the top 10 server Distributions to be run under it.  Of course you 
are not going to be using any stock kernel from those Distros if they 
don't support running other distros.   I would not bring it up if I had 
not run OpenSuse Fedora and Debian and other distros of the same kernel 
before.   How simple in initrd load the LSM for the Distro that was 
it.   There is no technical problem at the kernel for doing it.  Also 
part of the reason why I despise static LSM's becoming only option cross 
distro performance testing of a kernel to see if there is a difference 
will be made harder since I will have to build the kernel more than 
once.    Now when I get to containers you are now saying I cannot do the 
same thing.

I know current LSM model does not fit well for this.   Because its a 
giant hooking solution.   This solution is not suitable to exist well 
with containers and massively limiting on security improvements to the 
over all os that can be done..

The LSM model needs ripping in two to work great with containers and 
along the way allow applications and users to take care of there own 
problems.

Enforcement modules and Controllers.

Controllers work on threads and processors created to allocate security 
limitations.   LSM level controller can grant higher security access to 
threads and processors than what they all ready have to the level of the 
LSM.  User/program level controllers can only remove permissions to do 
things this is most likely better as a feature of the Enforcement 
modules.   LSM level controllers have to be attached to kernel or a 
security containers.  Since a container could all ready have limits from 
another LSMs put on it could only allocate permissions inside those limts.

Enforcement is exactly that.    Enforcement modules would be like posix 
file caps and so on.  An option has to be choose here if  Enforcement 
modules have to report to LSM level controller on secuirty change 
request to lower and expand or only to expand or not at all.  Not at all 
being default because it could be a new feature the controller does not 
know how to handle or want to handle.   Most likely this would be 
controller option on what if any information it wants out of the 
Enforcement modules.   Default operation of all enforcement modules is 
like posix file caps is lower only.     No option to expand what has all 
ready been given.   With a LSM controller asking to be given notice of 
change of a Enforcement section it can allow raising or forbid 
lowering.  Applications developers like GUI Filemanagers wine... Can 
depend on the Enforcement parts always being there.

This is a overall system wide upgrade of security  that does not fail 
completely just because you disable the contoller.   Because if all 
applications are doing there own internal thread based and process id 
based enforcements what can be far tighter than what any controller can 
do since they know what the application should be doing where.

I hear different people asking for a LSM to be build into kernel.   This 
is not a  requirement.    The enforcement features of LSM's are.  Each 
one of the enforcement features is a upgrade to the overall security of 
the operating system no matter the LSM loaded or even if LSM is loaded.

Basically just like containers take responsibility for parts 
individually when put  into once piece become a virtual server.   The 
same needs to be done with LSM's.    The controller is the final thing 
that joins the parts up.   Not coming with the parts in one huge blob as 
LSM do now.  The huge blob problem is why they don't want to work right 
containers.  Over head is small with
Controllers.  From Enforcement module to Controller is always the same 
depth.  When Controller goes to change permissions its checked against 
the list its allowed.   At this point does not matter if you are 1 deep 
or 1000 deep.   Since there is no need to go any deeper or run other 
Controllers to get information.   Just the first Controller the one you 
might statically build in gets told it has every permission to do 
whatever it sees fit maybe.   The first Controller at build time could 
have its rights limited.  Just like selinux strict mode for all.  As you 
can see 100 percent the same path level no matter what.  Only thing that 
changes in what controller you are in.

As bad as it sounds to some people doing this will lower the security 
difference between selinux apparmor or other LSM's .  This forces user 
and security friendly solutions out of LSM makers.  Yes true completion 
to produce the best and leave users as least exposed as able.   Not my 
LSM is better than yours arguments with complexity of comparing.  It 
will be simpler to compare LSM's ok what enforcement modules does it 
control.   Does that cover the area I need.   Then look at how it 
controls them and choose.

Note LSM controllers could be Security Containers.   Just one Container 
is set default off the start line.

Peter Dolding

Re: LSM and Containers

[Peter Dolding]

The other thing you have not though of and is critical.  If LSM is the
same LSM across all containers.  What happens if that is breached and
tripped to disable.  You only want to loss one container to a breach
not the whole box and dice in one hit.  Its also the reason why my
design does not have a direct link between controllers.  No cascade
threw system to take box and dice.

The more I look at it more holes I find why the current LSM model just
cannot keep on existing with Containers.   Its not the best option.
Hacking it to work with containers is only creating risks of more
problems.  The LSM model as also breed that problem of not sharing
security tech advantages to everyone.  Ie if they don't use our LSM
they don't need/deserve our defense.

Different LSM per container from a security point of view appears
critical.  Sorry to say redesign from the ground up time everyone.
Its a round peg into a square hole yes you can bash it in but it will
never fit right.

Peter Dolding

ps sorry for going on so long I just see this as a major problem.   If
you have a solution to it tell me.  Since a cut line has be put
somewhere with containers.

Re: LSM and Containers

[Crispin Cowan]

Peter Dolding wrote:
> The other thing you have not though of and is critical.  If LSM is the
> same LSM across all containers.  What happens if that is breached and
> tripped to disable.  You only want to loss one container to a breach
> not the whole box and dice in one hit.  Its also the reason why my
> design does not have a direct link between controllers.  No cascade
> threw system to take box and dice.
>   
Sorry, but I totally disagree.

If you obtain enough privilege to disable the LSM in one container, you
also obtain enough privilege to disable *other* LSMs that might be
operating in different containers. This is a limitation of the
Containers feature, not of LSM.

The purpose of LSM would be to manage privilege such that you cannot do
damage, and in particular, any LSM that fails to prevent an attacker
from disabling the LSM itself has failed, either in design, or in having
an inadequate policy in place.

> The more I look at it more holes I find why the current LSM model just
> cannot keep on existing with Containers.   Its not the best option.
> Hacking it to work with containers is only creating risks of more
> problems.  The LSM model as also breed that problem of not sharing
> security tech advantages to everyone.  Ie if they don't use our LSM
> they don't need/deserve our defense.
>   
Again, I completely disagree.

Well, I agree that the hacking you proposed to permit different LSMs in
different containers is a bad idea, so lets not do that :)

I see no need to support different LSMs in different containers. The
complexity of such a feature would be very high. The utility strikes me
as being very low; people who want that degree of separation of
containers should be using Xen or KVM, not Containers.

> Different LSM per container from a security point of view appears
> critical.  Sorry to say redesign from the ground up time everyone.
> Its a round peg into a square hole yes you can bash it in but it will
> never fit right.
>   
I have no idea how you can support such assertions. Absolutely not. It
is quite clear that the way to address security for containers is to
enhance individual LSM modules to be container-aware so that you can
have separate policies in the separate containers. That is in keeping
with the spirit of sharing the kernel, and providing separate instances
to the users.

> ps sorry for going on so long I just see this as a major problem.   If
> you have a solution to it tell me.  Since a cut line has be put
> somewhere with containers.
>   
Where as I see it as a very minor problem, and very easy to fix without
any re-design of LSM, or of Containers. It only requires container-aware
LSM modules.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
	       Itanium. Vista. GPLv3. Complexity at work

Re: LSM and Containers

[Peter Dolding]

On 10/25/07, Crispin Cowan <crispin@crispincowan.com> wrote:
> Peter Dolding wrote:
> > The other thing you have not though of and is critical.  If LSM is the
> > same LSM across all containers.  What happens if that is breached and
> > tripped to disable.  You only want to loss one container to a breach
> > not the whole box and dice in one hit.  Its also the reason why my
> > design does not have a direct link between controllers.  No cascade
> > threw system to take box and dice.
> >
> Sorry, but I totally disagree.
>
> If you obtain enough privilege to disable the LSM in one container, you
> also obtain enough privilege to disable *other* LSMs that might be
> operating in different containers. This is a limitation of the
> Containers feature, not of LSM.
>
That is not a Container feature.   If you have enough privilege does
not mean you can.  Root user in a Container does not mean you can play
with other containers applications.  There is a security split at the
container edge when doing Virtual Servers what by using one LSM you
are disregarding.

Simple point if one LSM is disabled in a container it can only get the
max rights of that Container.  So cannot see the other LSM's on the
system bellow it.  Reason also why in my model its the same layout if
there is 1 or 1000 stacked so attack cannot tell how deep they are in
and if there is anything to be gained by digging.  You have to break
the Security Container as well to get higher.   Of course breaking the
base LSM you would have problems the one with full powers of the
system and the right to kill and control the containers bellow it.
Most likely it would be wise to run that just for limited operations.
Really limited operations.

I think you need to go any play with Solaris some time what containers
can do is quite impressive.  Right upto changing the syscalls and
device names inside them.  Now its only going to get tricker if
someone brings in Freebsd and Solaris emulation containers into linux.
 Yes this is still just using the Linux kernel.  Because LSM's don't
exist on them you will want to plug in a module to suit the platform
contained inside the container.  In particular something different to
process the security configs even if the same enforcement code is
used.

You are dealing with something far more powerful current model is not
going to fit.  I look long term and I just cannot find what you are
doing is going to fit in anyway shape or form.  Just different Linux
distros is the simple form of containers not is fully grown form.
This is the problem if you cannot do that  future of containers will
have problems because LSM will be limiting its forms.

To rebuild a security framework takes time.  Its time to pull head out
sand that containers are not simple thing that what has worked in past
with small alterations will work with it in future.

Containers are completely new system with completely new problems.
LSM's should not interfere with its development.

What you are doing is having each LSM create its own outer shield.
With its own weaknesses.    Common Security Container makes only one
shield at edge of containers to maintain and look after.    Does not
different  weakness to track down and fix on a LSM by LSM base.

Peter Dolding

Re: LSM and Containers

[Serge E. Hallyn]

Quoting Peter Dolding (oiaohm@gmail.com):
> On 10/25/07, Crispin Cowan <crispin@crispincowan.com> wrote:
> > Peter Dolding wrote:
> > > The other thing you have not though of and is critical.  If LSM is the
> > > same LSM across all containers.  What happens if that is breached and
> > > tripped to disable.  You only want to loss one container to a breach
> > > not the whole box and dice in one hit.  Its also the reason why my
> > > design does not have a direct link between controllers.  No cascade
> > > threw system to take box and dice.
> > >
> > Sorry, but I totally disagree.
> >
> > If you obtain enough privilege to disable the LSM in one container, you
> > also obtain enough privilege to disable *other* LSMs that might be
> > operating in different containers. This is a limitation of the
> > Containers feature, not of LSM.
> >
> That is not a Container feature.   If you have enough privilege does
> not mean you can.  Root user in a Container does not mean you can play
> with other containers applications.  There is a security split at the
> container edge when doing Virtual Servers what by using one LSM you
> are disregarding.
> 
> Simple point if one LSM is disabled in a container it can only get the
> max rights of that Container.  So cannot see the other LSM's on the
> system bellow it.  Reason also why in my model its the same layout if
> there is 1 or 1000 stacked so attack cannot tell how deep they are in
> and if there is anything to be gained by digging.  You have to break

You're sometimes hard to parse, but here are a few basic facts within
which to constrain our discussions:

	1. LSMs are a part of the kernel.  The entire kernel is in the
	   same trusted computing base
	2. containers all run on the same kernel
	3. whether an lsm is compromised, or a tty driver, or anything
	   else which is in the TCB, all containers are compromised
	4. it is very explicitly NOT a goal to hide from a container
	   the fact that it is in a container.  So your 'cannot tell how
	   deep they are' is not a goal.

If you want to be able to 'plug' lsms in per container, by all means
feel free to write a proof of concept.  It is kind of a cool idea.  But
be clear about what you'll gain:  You allow the container admin to
contrain data access within his container in the way he chooses using
the model with which he is comfortable.  It does nothing to protect one
container from another, does nothing to protect against kernel exploits,
and absolutely does nothing to protect a container from the 'host'.

Also please keep in mind that the container security framework is not
only not yet complete, it's pretty much not started.  My own idea for
how to best do it are outlined in emails which are in the containers
list archive.  But in terms of LSM they follow the idea Crispin
outlines, namely that the LSMs support containers themselves.  And, in
a proces in a container started without CAP_NS_OVERRIDE (which does not
yet exist :) in its capability bounding set will only be able to access
files in another container as DAC user 'other' (i.e if perms are 754, it
will get read access, if 750, then none), even if it has
CAP_DAC_OVERRIDE.  (unless it gets an authorization key for the owning
user in the target namespace, but *that's* probably *years* off)

-serge

Re: LSM and Containers

[Peter Dolding]

> You're sometimes hard to parse, but here are a few basic facts within
> which to constrain our discussions:
>
>         1. LSMs are a part of the kernel.  The entire kernel is in the
>            same trusted computing base
>         2. containers all run on the same kernel
>         3. whether an lsm is compromised, or a tty driver, or anything
>            else which is in the TCB, all containers are compromised
>         4. it is very explicitly NOT a goal to hide from a container
>            the fact that it is in a container.  So your 'cannot tell how
>            deep they are' is not a goal.
You are missing what I am saying.

I am breaking the LSM in two.  Kernel level comprise that is out of my hands.

If you wished in mine the controller could be user space run outside
kernel does not have to stay in the TCB.  Since its not having any
direct control on the approval or rejection of access.  Its only
queried when needed like when a process breaches the rules applied to
it or when processes start or changing security.   So breaching it
turning it off and so on.  This is to reduce the risk of someone
trying to customize a LSM can cause a security flaw of hell
level(Inside kernel space).

With Intel's and Amd new memory table splitting yes the controller
could be put away from the main kernel in time with the rest of the
container only data.  Yes less bits trusted.  This includes when
sending the container between machines the controller with it current
state could be sent with it.  If the interface to controller is
standard of course.  Ok apparmor and selinux will cope with your
system but some of the more complex state based need to transfer state
as well this should be in the controller bit of a LSM and not mixed up
with the state of the overall machine either.

Over all this is making it simpler to do advanced container things
like sending between servers.

The permission enforcement parts stay the same no matter the
controller in use.  Breaching the enforcement parts still remain a
problem.  Allows running many controllers unlike LSM's where they can
fight and on way around that cleanly.  Just like LSM two controllers
controlling the same space would still fight so guess how many each
container take 1.   Since a different controller has to be give its
own zone.  So people cannot complain about not being able to run there
preferred controller if they want a different one they have to give it
a different zone.  Yes this is getting on top of a lot of long term
problems of people wanting a or b LSM. Stuff it have both and be
happy.

Its also removing the single overall kill switch.   And replacing them
with a per container kill switches.   So someone does what will
normally turn X controller off and it does.   Yet still the outside
security is applied to everything run in the container.   Security is
lowed but not off.

The controllers don't need to keep track of how deep they are.  They
just don't need to know.  From there point of view the world ends from
there startup security settings.  Only time the controller would have
to be give notice is if those outside security settings were changed
so it could update the programs under it to the way it wanted.  Even
that the security settings if they were lower would have just been
brute forced applied.  Basically its  have you done containers running
containers is you model Serge E. Hallyn.  This avoids have to much
around with flags for the next container in.  Only thing in mine are
you doing is changing the path back to the controller from the
security enforcing modules.  Enforcing modules process not doing
permissions were told to allow I report that to x secuirty container
that reports it to contoller.  Note the security container only hands
out what its allowed nothing more the controller is not trusted.   No
processing to work out what security files it should be using since
the controller only knows the files it should be using.

Yes there is overhead in my system.  But were able the system is
avoiding traveling in a perfectly functioning system controller could
be only being bothered when new processors were being created the rest
of the time the enforcement modules just do there job as they were
configured.

Traveling down a tree of stacked LSM is going to cause massive lag. Ie
knowing that something is below you.  Not knowing reduces travel and
time to resolve.  And allows security to be controlled over the
complete container from one spot.  The problem with running many LSM
again having to tweek them all to get it locked down on container.  Ie
enabling some disabling others so simple to loss track and have big
problems.  No problem here the secuirty model is applied to the
container and if you want to lock its outside down you just do and the
controller inside has to cope.  Yes it will be possible to take too
much away from a security container.  Ok this security container
should not have access to that device slam not a question.  With
running many LSM the question what one does that container own to so I
do turn that device off and not have another LSM turn it back on.

Besides having selinux and apparmor installed side by side is going to
lag the system due to overlapping hooks.   This what I am avoiding.
The enforcement modules are only hooked in once no reason at all to
overlap them.  This overlapping is what makes running many LSM
problematic.

The outside security on a container will stay on even if the host LSM
is turned off in the design I am look at.  It was set when the
container started and would have to be directly updated.  The outside
security defined to a container would be everything selinux could do
to a program and then some. Just like selinux opt in.

Over lapping I am handling differently in this design.   The outside
security set on the container covers overlaps.  Far more flex able
option.  Using directory filtering and other options are on the table
as well as far more complex cap options.  My design depends on the
common protective modules.   Not the bit that says this is Mac or Role
based or State or so on.

Basically apparmor and selinux would be sitting on the same engine
that everyone can use to build solid controllers.  If you want a new
enforcement feature you would add it for everyone.  Since altering the
controller would be toothless only can tweak what already exists since
you can never be sure its even in kernel space no direct tweaking no
hooking no bad stuff with controllers.

There is a security advantage from the design change even for people
not using containers or LSM.   Everything in system can apply LSM
style restrictions lower than what it has to what it wants to run even
if a controller is present or not.   The controller is to provide the
security model in use.  With the enforcement system you could almost
do any security model with user space code.  The difference being not
catching process starts to apply security to them.  This is useful for
programs running untrusted content web browers that java program
running from web does not need all the access I am cut it back.
Application level security something LSM overlook and it not wise to
use different interfaces for it.

Yes these are major changes in design.  Yes they will force clear
designs and more sharing so everyone can take advantage of
advancements.  As well should kill off lots of problems of  poor
quality LSM's and LSM limitations.  Basically my design and LSM cannot
live side by side effectively.

Peter Dolding