Re: LSM conversion to static interface

Re: LSM conversion to static interface

[Thomas Fricaccia]

Yes, I think Crispin has succinctly summed it up:  irrevocably closing
the LSM prevents commercial customers from using security modules other
than that provided by their Linux distributor.  As Sarbanes-Oxley and
other regulatory laws require these customers to use "standard
kernels", the result is a rather dreary form of vendor lock-in, where the
security framework is coupled to the distribution.

Though it would require a somewhat undesirable complexity of CONFIG_
flags, it should be possible to construct flexibility enough for everyone
to get what he wants.  For example, it should be possible to configure
kernels with a single security framework hard-linked, AND it should
also be possible to configure kernels such that the default security
framework could be completely replaced at boot time by another, be it
out-of-tree module, or other.

I agree entirely that preserving this form of freedom for the end user
makes Linux a much stronger technology than not.  For one thing, the
consequences of closing LSM are fairly certain to irritate enterprise
commercial customers, which is probably a sign that the technology has
taken a wrong turn.

Tommy F.


Crispin Cowan <crispin@crispincowan.com> wrote:

> So the net impact of this patch is:
> 
>    * It takes a deployment practice (static compiled-in security) that
>      is arguably good in many circumstances and makes it mandatory at
>      all times.
>    * It takes a development practice that is very convenient and
>      slightly risky, and forces you into the pessimal inconvenient
>      development practice at all times.
>    * It prevents enterprise users, and in fact anyone who isn't
>      comfortable compiling their own kernel, from ever trying out any
>      security module that their distro vendor of choice did not ship.
>
> This strikes me as a rather anti-choice position to take. It says that
> because candy is bad for you, you only ever get to eat vegetables. I
> don't understand why Linux would want to do this to its users.
>
> It doesn't hurt me or AppArmor. Since AppArmor is now shipping with
> SUSE, Ubuntu, and Mandriva, what this does is make it harder for newer
> modules like TOMOYO, Multi-Admin, etc, to get exposure to enterprise
> users. So I don't think I am being self-serving in arguing against this
> patch. I just think it is bad for Linux.
>
> Crispin
>
> -- 
> Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
>         Itanium. Vista. GPLv3. Complexity at work

Re: LSM conversion to static interface

[Greg KH]

On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
> the LSM prevents commercial customers from using security modules other
> than that provided by their Linux distributor.

Any "customer" using a security model other than provided by their Linux
distributor instantly voided all support from that distro by doing that.

So, since the support is gone, they can easily build their own kernels,
with their own LSM interfaces, and get the exact same lack of support :)

And, what are these "other LSM modules" you speak of that people rely on
to run their businesses?

> As Sarbanes-Oxley and
> other regulatory laws require these customers to use "standard
> kernels", the result is a rather dreary form of vendor lock-in, where the
> security framework is coupled to the distribution.

Wait, what?

Since when does Sarbanes-Oxley decree that a company must use a
"standard kernel"?  And just exactly what defines such "standard
kernel"?  Can you point out where in that bill it requires such a thing?

Totally confused,

greg k-h

Re: LSM conversion to static interface

[Alan Cox]

On Sun, 21 Oct 2007 19:24:42 -0700
"Thomas Fricaccia" <thomas_fricacci@yahoo.com> wrote:

> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
> the LSM prevents commercial customers from using security modules other
> than that provided by their Linux distributor.  As Sarbanes-Oxley and
> other regulatory laws require these customers to use "standard
> kernels", the result is a rather dreary form of vendor lock-in, where the
> security framework is coupled to the distribution.

Crispin at least is providing genuine discussion points. Sarbox has
nothing to say on "using vendor linux kernels".

Re: LSM conversion to static interface

[Crispin Cowan]

Alan Cox wrote:
> On Sun, 21 Oct 2007 19:24:42 -0700
> "Thomas Fricaccia" <thomas_fricacci@yahoo.com> wrote
>> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
>> the LSM prevents commercial customers from using security modules other
>> than that provided by their Linux distributor.  As Sarbanes-Oxley and
>> other regulatory laws require these customers to use "standard
>> kernels", the result is a rather dreary form of vendor lock-in, where the
>> security framework is coupled to the distribution.
>>     
> Crispin at least is providing genuine discussion points. Sarbox has
> nothing to say on "using vendor linux kernels".
>   
I agree that SarBox is not really the issue here. Partially related is
enterprise rules about what kernels one is allowed to load. More
generally, this change forces users who want to use a different LSM than
their vendor provides to recompile their kernel, where they did not have
to recompile before. It forces LSM module developers who want to modify
their LSM to reboot, where they didn't necessarily have to reboot before.

That is not a catastrophe, it is just tedious. It does not kill baby
seals, and it does not make Linux utterly useless. OTOH, I think it is
strictly negative: it takes away user choice in 2 dimensions, and adds
zero value. So apply it if you must to bake the kernel developer's lives
easier, but it really is a net loss in Linux kernel capability.

Crispin

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

Re: LSM conversion to static interface

[Alan Cox]

> > Crispin at least is providing genuine discussion points. Sarbox has
> > nothing to say on "using vendor linux kernels".
> >   
> I agree that SarBox is not really the issue here. Partially related is
> enterprise rules about what kernels one is allowed to load. More
> generally, this change forces users who want to use a different LSM than
> their vendor provides to recompile their kernel, where they did not have
> to recompile before. It forces LSM module developers who want to modify
> their LSM to reboot, where they didn't necessarily have to reboot before.

The moment they load a module from a third party they usually hit support
issues, unless there is some kind of arrangement between the parties.

> 
> That is not a catastrophe, it is just tedious. It does not kill baby
> seals, and it does not make Linux utterly useless. OTOH, I think it is
> strictly negative: it takes away user choice in 2 dimensions, and adds
> zero value. So apply it if you must to bake the kernel developer's lives
> easier, but it really is a net loss in Linux kernel capability.

Frankly I don't care about apparmor, I don't see it as a serious project.
Smack is kind of neat but looks like a nicer way to specify selinux rules.

What I do care about is that at some point something is going to appear
which is based on all the same good practice and experience and forty
years of research that leads towards SELinux, and which is much better. At
that point there will be a changeover phase and the LSM is exactly what
is needed for this.

The fact it allows people to play with toy security systems, propose new
ones like SMACK, and do research and PhD work on Linux into security is a
convenient and very good side effect.

For that reason I think keeping LSM is the right thing to do.

Alan

Re: LSM conversion to static interface

[Greg KH]

On Mon, Oct 22, 2007 at 05:50:43PM +0100, Alan Cox wrote:
> 
> For that reason I think keeping LSM is the right thing to do.

Wait, we aren't talking about dropping LSM at all, just the "LSM is a
module" option.  That's it.  And by making LSM not a module, we can then
go on to fix some of the reported speed issues that are present with the
LSM option enabled right now.

thanks,

greg k-h

Re: LSM conversion to static interface

[Avi Kivity]

Greg KH wrote:
> On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
>   
>> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
>> the LSM prevents commercial customers from using security modules other
>> than that provided by their Linux distributor.
>>     
>
> Any "customer" using a security model other than provided by their Linux
> distributor instantly voided all support from that distro by doing that.
>
> So, since the support is gone, they can easily build their own kernels,
> with their own LSM interfaces, and get the exact same lack of support :)
>
>   

Running a vendor kernel has the advantage of reusing all the QA work 
that has gone into that kernel.  It is very different from running 
2.6.24-rc1 (or 2.6.22.x).  Hence projects like centos: you don't get any 
support, but the likelihood of actually requiring support is lower than 
running some random kernel.

[but I agree that someone who has somehow determined that they need a 
specific LSM will probably have determined that they need vendor support 
as well]

-- 
error compiling committee.c: too many arguments to function

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 conversion to static interface

[Adrian Bunk]

On Mon, Oct 22, 2007 at 07:47:36PM +0200, Avi Kivity wrote:
> Greg KH wrote:
>> On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
>>   
>>> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
>>> the LSM prevents commercial customers from using security modules other
>>> than that provided by their Linux distributor.
>>>     
>>
>> Any "customer" using a security model other than provided by their Linux
>> distributor instantly voided all support from that distro by doing that.
>>
>> So, since the support is gone, they can easily build their own kernels,
>> with their own LSM interfaces, and get the exact same lack of support :)
>
> Running a vendor kernel has the advantage of reusing all the QA work that 
> has gone into that kernel.  It is very different from running 2.6.24-rc1 
> (or 2.6.22.x).  Hence projects like centos: you don't get any support, but 
> the likelihood of actually requiring support is lower than running some 
> random kernel.

You can also get the QA work by building your own kernel from vendor 
kernel sources.

E.g. the Debian distribution ships a package linux-source-2.6.18 that 
contains a linux-source-2.6.18.tar.bz2 with the patched 2.6.18 kernel 
sources Debian uses for building its kernels.

> [but I agree that someone who has somehow determined that they need a 
> specific LSM will probably have determined that they need vendor support as 
> well]

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: LSM conversion to static interface

[Geert Uytterhoeven]

On Sun, 21 Oct 2007, Greg KH wrote:
> On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
> > As Sarbanes-Oxley and
> > other regulatory laws require these customers to use "standard
> > kernels", the result is a rather dreary form of vendor lock-in, where the
> > security framework is coupled to the distribution.
> 
> Wait, what?
> 
> Since when does Sarbanes-Oxley decree that a company must use a
> "standard kernel"?  And just exactly what defines such "standard
> kernel"?  Can you point out where in that bill it requires such a thing?

Simple, these days Sarbanes-Oxley is the default argument behind anything being
pushed down your throat in a company.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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