[LSM Stacking] SELinux policy inside container affects a process on Host

[LSM Stacking] SELinux policy inside container affects a process on Host

[Leesoo Ahn]

Hello! Here is another weird behavior of lsm stacking..

test env
- Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38
- boot param: lsm=apparmor,selinux
- AppArmor (Host) + SELinux (LXD Container Fedora 36)

In the test environment mentioned above and applying selinux policy 
enforcing by running "setenforce 1" within the container, executing the 
following command on the host will result in "Permission denied" output.

root@stack-v6:/home/lsahn# insmod 
/lib/modules/6.2.0-20-generic/kernel/net/netfilter/nft_ct.ko
insmod: ERROR: could not insert module 
/lib/modules/6.2.0-20-generic/kernel/net/netfilter/nft_ct.ko: Permission 
denied

In dmesg, the following kernel log is displayed,

[  +0.000003] audit: type=1400 audit(1688619411.654:1072): avc:  denied 
{ module_load } for  pid=67703 comm="insmod" 
path="/usr/lib/modules/6.2.0-20-generic/kernel/net/netfilter/nft_ct.ko" 
dev="sda2" ino=1444804 scontext=system_u:system_r:kernel_t:s0 
tcontext=system_u:object_r:unlabeled_t:s0 tclass=system permissive=0

I have the following questions by the results:
- Why the policy applied within the container affects the host? and 
whether it is a bug or not.
- If this is a bug, I'm curious about where to start the analysis. It 
would be helpful if you could provide relevant resources or links.

best regards,
Leesoo

Re: [LSM Stacking] SELinux policy inside container affects a process on Host

[Paul Moore]

On Thu, Jul 6, 2023 at 1:20 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
>
> Hello! Here is another weird behavior of lsm stacking..
>
> test env
> - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38
> - boot param: lsm=apparmor,selinux
> - AppArmor (Host) + SELinux (LXD Container Fedora 36)
>
> In the test environment mentioned above and applying selinux policy
> enforcing by running "setenforce 1" within the container, executing the
> following command on the host will result in "Permission denied" output.

SELinux operates independently of containers, or kernel namespacing in
general.  When you load a SELinux policy it applies to all processes
on the system, regardless of where they are in relation to the process
which loaded the policy into the kernel.

This behavior is independent of the LSM stacking work, you should be
able to see the same behavior even in cases where SELinux is the only
loaded LSM on the system.

-- 
paul-moore.com

Re: [LSM Stacking] SELinux policy inside container affects a process on Host

[Serge E. Hallyn]

On Thu, Jul 06, 2023 at 09:43:01AM -0400, Paul Moore wrote:
> On Thu, Jul 6, 2023 at 1:20 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
> >
> > Hello! Here is another weird behavior of lsm stacking..
> >
> > test env
> > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38
> > - boot param: lsm=apparmor,selinux
> > - AppArmor (Host) + SELinux (LXD Container Fedora 36)
> >
> > In the test environment mentioned above and applying selinux policy
> > enforcing by running "setenforce 1" within the container, executing the
> > following command on the host will result in "Permission denied" output.
> 
> SELinux operates independently of containers, or kernel namespacing in
> general.  When you load a SELinux policy it applies to all processes
> on the system, regardless of where they are in relation to the process
> which loaded the policy into the kernel.
> 
> This behavior is independent of the LSM stacking work, you should be
> able to see the same behavior even in cases where SELinux is the only

The real question might be what kind of container was this?  Since it
was allowed to setenforce 1, it must not have been in a user namespace?
Did you do "lxc config set c1 security.privileged true" ?

Re: [LSM Stacking] SELinux policy inside container affects a processon Host

[Leesoo Ahn]

2023-07-07 오전 9:36에 Serge E. Hallyn 이(가) 쓴 글:
> On Thu, Jul 06, 2023 at 09:43:01AM -0400, Paul Moore wrote:
>  > On Thu, Jul 6, 2023 at 1:20 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
>  > >
>  > > Hello! Here is another weird behavior of lsm stacking..
>  > >
>  > > test env
>  > > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38
>  > > - boot param: lsm=apparmor,selinux
>  > > - AppArmor (Host) + SELinux (LXD Container Fedora 36)
>  > >
>  > > In the test environment mentioned above and applying selinux policy
>  > > enforcing by running "setenforce 1" within the container, executing the
>  > > following command on the host will result in "Permission denied" 
> output.
>  >
>  > SELinux operates independently of containers, or kernel namespacing in
>  > general. When you load a SELinux policy it applies to all processes
>  > on the system, regardless of where they are in relation to the process
>  > which loaded the policy into the kernel.
>  >
>  > This behavior is independent of the LSM stacking work, you should be
>  > able to see the same behavior even in cases where SELinux is the only
> 
> The real question might be what kind of container was this? Since it
> was allowed to setenforce 1, it must not have been in a user namespace?
> Did you do "lxc config set c1 security.privileged true" ?

Yes, I did. For a reason that I wanted to use SELinux policy in 
Enforcing mode inside container and expected it applied to only 
container side.

Re: [LSM Stacking] SELinux policy inside container affects a process on Host

[Leesoo Ahn]

2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글:
> On Thu, Jul 6, 2023 at 1:20 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
>  >
>  > Hello! Here is another weird behavior of lsm stacking..
>  >
>  > test env
>  > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38
>  > - boot param: lsm=apparmor,selinux
>  > - AppArmor (Host) + SELinux (LXD Container Fedora 36)
>  >
>  > In the test environment mentioned above and applying selinux policy
>  > enforcing by running "setenforce 1" within the container, executing the
>  > following command on the host will result in "Permission denied" output.
> 
> SELinux operates independently of containers, or kernel namespacing in
> general. When you load a SELinux policy it applies to all processes
> on the system, regardless of where they are in relation to the process
> which loaded the policy into the kernel.
> 
> This behavior is independent of the LSM stacking work, you should be
> able to see the same behavior even in cases where SELinux is the only
> loaded LSM on the system.

Thank you for the reply!

So as far as I understand, the environment of LSM Stacking,
AppArmor (Host) + SELinux (Container) couldn't provide features "using 
SELinux policy inside the container shouldn't affect to the host side" 
for now.

If so, I wonder if you and Casey plan to design future features like 
that, because my co-workers and I are considering taking LSM stacking of 
AppArmor + SELinux in products that both policies must be working 
separately.

best regards,
Leesoo

Re: [LSM Stacking] SELinux policy inside container affects a process on Host

[Paul Moore]

On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
> 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글:
> > On Thu, Jul 6, 2023 at 1:20 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
> >  >
> >  > Hello! Here is another weird behavior of lsm stacking..
> >  >
> >  > test env
> >  > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38
> >  > - boot param: lsm=apparmor,selinux
> >  > - AppArmor (Host) + SELinux (LXD Container Fedora 36)
> >  >
> >  > In the test environment mentioned above and applying selinux policy
> >  > enforcing by running "setenforce 1" within the container, executing the
> >  > following command on the host will result in "Permission denied" output.
> >
> > SELinux operates independently of containers, or kernel namespacing in
> > general. When you load a SELinux policy it applies to all processes
> > on the system, regardless of where they are in relation to the process
> > which loaded the policy into the kernel.
> >
> > This behavior is independent of the LSM stacking work, you should be
> > able to see the same behavior even in cases where SELinux is the only
> > loaded LSM on the system.
>
> Thank you for the reply!
>
> So as far as I understand, the environment of LSM Stacking,
> AppArmor (Host) + SELinux (Container) couldn't provide features "using
> SELinux policy inside the container shouldn't affect to the host side"
> for now.
>
> If so, I wonder if you and Casey plan to design future features like
> that, because my co-workers and I are considering taking LSM stacking of
> AppArmor + SELinux in products that both policies must be working
> separately.

What you are looking for is a combination of LSM stacking and
individual LSM namespacing.  Sadly, I think the communications around
LSM stacking have not been very clear on this and I worry that many
people are going to be disappointed with LSM stacking for this very
reason.

While stacking of LSMs is largely done at the LSM layer, namespacing
LSMs such that they can be customized for individual containers
requires work to be done at the per-LSM level as each LSM is
different.  AppArmor already has a namespacing concept, but SELinux
does not.  Due to differences in the approach taken by the two LSMs,
namespacing is much more of a challenge for SELinux, largely due to
issues around filesystem labeling.  We have not given up on the idea,
but we have yet to arrive at a viable solution for namespacing
SELinux.

If you are interested in stacking SELinux and AppArmor, I believe the
only practical solution is to run SELinux on the host system (initial
namespace) and run AppArmor in the containers.  Even in a world where
SELinux is fully namespaced, it would likely still be necessary to run
some type of SELinux policy on the host (initial namespace) in order
to support SELinux policies in the containers.

-- 
paul-moore.com

Re: [LSM Stacking] SELinux policy inside container affects a process on Host

[Casey Schaufler]

On 7/7/2023 7:20 AM, Paul Moore wrote:
> On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
>> 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글:
>>> On Thu, Jul 6, 2023 at 1:20 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
>>>  >
>>>  > Hello! Here is another weird behavior of lsm stacking..
>>>  >
>>>  > test env
>>>  > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38
>>>  > - boot param: lsm=apparmor,selinux
>>>  > - AppArmor (Host) + SELinux (LXD Container Fedora 36)
>>>  >
>>>  > In the test environment mentioned above and applying selinux policy
>>>  > enforcing by running "setenforce 1" within the container, executing the
>>>  > following command on the host will result in "Permission denied" output.
>>>
>>> SELinux operates independently of containers, or kernel namespacing in
>>> general. When you load a SELinux policy it applies to all processes
>>> on the system, regardless of where they are in relation to the process
>>> which loaded the policy into the kernel.
>>>
>>> This behavior is independent of the LSM stacking work, you should be
>>> able to see the same behavior even in cases where SELinux is the only
>>> loaded LSM on the system.
>> Thank you for the reply!
>>
>> So as far as I understand, the environment of LSM Stacking,
>> AppArmor (Host) + SELinux (Container) couldn't provide features "using
>> SELinux policy inside the container shouldn't affect to the host side"
>> for now.
>>
>> If so, I wonder if you and Casey plan to design future features like
>> that, because my co-workers and I are considering taking LSM stacking of
>> AppArmor + SELinux in products that both policies must be working
>> separately.
> What you are looking for is a combination of LSM stacking and
> individual LSM namespacing.  Sadly, I think the communications around
> LSM stacking have not been very clear on this and I worry that many
> people are going to be disappointed with LSM stacking for this very
> reason.

There have been many discussions regarding the viability of the using
different LSM policies in containers. Some of these discussions have
been quite lively. I have never claimed that LSM stacking addresses
all of the possible use cases for multiple concurrent LSMs. If people
are disappointed by how little they can accomplish with what is currently
being proposed I can only say that we can't get on to the next phase
until this work is complete. 

>
> While stacking of LSMs is largely done at the LSM layer, namespacing
> LSMs such that they can be customized for individual containers
> requires work to be done at the per-LSM level as each LSM is
> different.  AppArmor already has a namespacing concept, but SELinux
> does not.  Due to differences in the approach taken by the two LSMs,
> namespacing is much more of a challenge for SELinux, largely due to
> issues around filesystem labeling.  We have not given up on the idea,
> but we have yet to arrive at a viable solution for namespacing
> SELinux.

I remain more optimistic than Paul about the options for supporting
generic LSM namespacing. I hope to explore a couple notions that I
have more fully, but as they depend on the current stacking work I
may not get to them very soon.

>
> If you are interested in stacking SELinux and AppArmor, I believe the
> only practical solution is to run SELinux on the host system (initial
> namespace) and run AppArmor in the containers.  Even in a world where
> SELinux is fully namespaced, it would likely still be necessary to run
> some type of SELinux policy on the host (initial namespace) in order
> to support SELinux policies in the containers.

SELinux policy is sufficiently flexible to support what would look like
different policies on the host system and in the container. I think that
the administration of such a system would be tricky, and the policy would
be very complex, but it could be done, for some use cases at least.

Re: [LSM Stacking] SELinux policy inside container affects a process on Host

[Dr. Greg]

On Fri, Jul 07, 2023 at 05:28:36PM +0900, Leesoo Ahn wrote:

Hi Leesoo, I hope the week has gone well for you.

> 2023-07-06 ?????? 10:43??? Paul Moore ???(???) ??? ???:
> >On Thu, Jul 6, 2023 at 1:20???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
> > >
> > > Hello! Here is another weird behavior of lsm stacking..
> > >
> > > test env
> > > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38
> > > - boot param: lsm=apparmor,selinux
> > > - AppArmor (Host) + SELinux (LXD Container Fedora 36)
> > >
> > > In the test environment mentioned above and applying selinux policy
> > > enforcing by running "setenforce 1" within the container, executing the
> > > following command on the host will result in "Permission denied" output.

> >SELinux operates independently of containers, or kernel namespacing in
> >general. When you load a SELinux policy it applies to all processes
> >on the system, regardless of where they are in relation to the process
> >which loaded the policy into the kernel.
> >
> >This behavior is independent of the LSM stacking work, you should be
> >able to see the same behavior even in cases where SELinux is the only
> >loaded LSM on the system.

> Thank you for the reply!
>
> So as far as I understand, the environment of LSM Stacking, AppArmor
> (Host) + SELinux (Container) couldn't provide features "using
> SELinux policy inside the container shouldn't affect to the host
> side" for now.
>
> If so, I wonder if you and Casey plan to design future features like
> that, because my co-workers and I are considering taking LSM
> stacking of AppArmor + SELinux in products that both policies must
> be working separately.

I see that Paul Moore has also replied and indicated that 'stacking'
doesn't imply either/or separation of security policy in a string of
LSM's.  As he also noted, it does not apply isolation and application
of security policy at the container or kernel resource namespace
level.

Just as an FYI, we will be releasing version 2 of our Trusted Security
Event Modeling (TSEM) LSM over the weekend for review and inclusion in
the upstream kernel.

TSEM 'stacks' with the other LSM's, but was architected from the
ground up to support the notion of security namespaces that operate
exclusively from one another, with the express goal of allowing
multiple and distinct security policies to be applied independently at
what would be considered the 'container' level.  Subordinate security
modeling namespaces also act independently from the security
model/policy that the 'root' modeling namespace is operating under.

TSEM is based on a mathematical modeling architecture that is
different from either the label or pathname based LSM's which allowed
us to sidestep some of the issues that are challenging with respect to
implementing full namespace support for those LSM's.

There is a sizable stack of documentation with TSEM that goes further
into all of this.  We also release a rather significant body of
userspace tooling that goes with the TSEM LSM to support running
'security containers', for lack of a better term.

It obviously takes a while to develop a security eco-system but TSEM
will hopefully offer security architects additional flexibility moving
forward.

> best regards,
> Leesoo

Have a good weekend.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity

Re: [LSM Stacking] SELinux policy inside container affects a process on Host

[Paul Moore]

On Fri, Jul 7, 2023 at 12:50 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 7/7/2023 7:20 AM, Paul Moore wrote:

...

> > What you are looking for is a combination of LSM stacking and
> > individual LSM namespacing.  Sadly, I think the communications around
> > LSM stacking have not been very clear on this and I worry that many
> > people are going to be disappointed with LSM stacking for this very
> > reason.
>
> There have been many discussions regarding the viability of the using
> different LSM policies in containers. Some of these discussions have
> been quite lively. I have never claimed that LSM stacking addresses
> all of the possible use cases for multiple concurrent LSMs. If people
> are disappointed by how little they can accomplish with what is currently
> being proposed I can only say that we can't get on to the next phase
> until this work is complete.

The issue of namespacing LSMs is independent of stacking.

> > While stacking of LSMs is largely done at the LSM layer, namespacing
> > LSMs such that they can be customized for individual containers
> > requires work to be done at the per-LSM level as each LSM is
> > different.  AppArmor already has a namespacing concept, but SELinux
> > does not.  Due to differences in the approach taken by the two LSMs,
> > namespacing is much more of a challenge for SELinux, largely due to
> > issues around filesystem labeling.  We have not given up on the idea,
> > but we have yet to arrive at a viable solution for namespacing
> > SELinux.
>
> I remain more optimistic than Paul about the options for supporting
> generic LSM namespacing. I hope to explore a couple notions that I
> have more fully, but as they depend on the current stacking work I
> may not get to them very soon.

I remain unconvinced that namespacing should be done at the LSM layer;
my opinion is that namespacing should be handled individually by the
LSMs.  Just as there is no single security model across LSMs, I don't
believe there should be a single approach to namespacing.

> > If you are interested in stacking SELinux and AppArmor, I believe the
> > only practical solution is to run SELinux on the host system (initial
> > namespace) and run AppArmor in the containers.  Even in a world where
> > SELinux is fully namespaced, it would likely still be necessary to run
> > some type of SELinux policy on the host (initial namespace) in order
> > to support SELinux policies in the containers.
>
> SELinux policy is sufficiently flexible to support what would look like
> different policies on the host system and in the container. I think that
> the administration of such a system would be tricky, and the policy would
> be very complex, but it could be done, for some use cases at least.

The concept of loading a separate SELinux policy into a container, and
having that policy apply only to that container, is not currently
possible.  Of course there are ways to introduce additional security
domains within the container with SELinux, but that requires
cooperation between the container and the host.  There are also
several different approaches available today for isolating containers
with SELinux, which tends to fit very well with most container
workloads, but I get the impression that is not what Leesoo is
interested in at the moment.

-- 
paul-moore.com

Re: [LSM Stacking] SELinux policy inside container affects a processon Host

[Leesoo Ahn]

23. 7. 7. 23:20에 Paul Moore 이(가) 쓴 글:
> On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
>  > 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글:
[...]
> 
> What you are looking for is a combination of LSM stacking and
> individual LSM namespacing. Sadly, I think the communications around
> LSM stacking have not been very clear on this and I worry that many
> people are going to be disappointed with LSM stacking for this very
> reason.
> 
> While stacking of LSMs is largely done at the LSM layer, namespacing
> LSMs such that they can be customized for individual containers
> requires work to be done at the per-LSM level as each LSM is
> different. AppArmor already has a namespacing concept, but SELinux
> does not. Due to differences in the approach taken by the two LSMs,
> namespacing is much more of a challenge for SELinux, largely due to
> issues around filesystem labeling. We have not given up on the idea,
> but we have yet to arrive at a viable solution for namespacing
> SELinux.
> 
> If you are interested in stacking SELinux and AppArmor, I believe the
> only practical solution is to run SELinux on the host system (initial
> namespace) and run AppArmor in the containers. Even in a world where
> SELinux is fully namespaced, it would likely still be necessary to run
> some type of SELinux policy on the host (initial namespace) in order
> to support SELinux policies in the containers.

Thank you for the reply. It really helped me to know the current status 
of them and what to do now.

Just a little information for who is interested in the stacking that we 
decided to branch the LSM hooks by which lsm the current process is in 
instead of entirely calling them in order.

Best regards,
Leesoo

Re: [LSM Stacking] SELinux policy inside container affects a processon Host

[Casey Schaufler]

On 7/17/2023 8:24 AM, Leesoo Ahn wrote:
> 23. 7. 7. 23:20에 Paul Moore 이(가) 쓴 글:
>> On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
>>  > 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글:
> [...]
>>
>> What you are looking for is a combination of LSM stacking and
>> individual LSM namespacing. Sadly, I think the communications around
>> LSM stacking have not been very clear on this and I worry that many
>> people are going to be disappointed with LSM stacking for this very
>> reason.
>>
>> While stacking of LSMs is largely done at the LSM layer, namespacing
>> LSMs such that they can be customized for individual containers
>> requires work to be done at the per-LSM level as each LSM is
>> different. AppArmor already has a namespacing concept, but SELinux
>> does not. Due to differences in the approach taken by the two LSMs,
>> namespacing is much more of a challenge for SELinux, largely due to
>> issues around filesystem labeling. We have not given up on the idea,
>> but we have yet to arrive at a viable solution for namespacing
>> SELinux.
>>
>> If you are interested in stacking SELinux and AppArmor, I believe the
>> only practical solution is to run SELinux on the host system (initial
>> namespace) and run AppArmor in the containers. Even in a world where
>> SELinux is fully namespaced, it would likely still be necessary to run
>> some type of SELinux policy on the host (initial namespace) in order
>> to support SELinux policies in the containers.
>
> Thank you for the reply. It really helped me to know the current
> status of them and what to do now.
>
> Just a little information for who is interested in the stacking that
> we decided to branch the LSM hooks by which lsm the current process is
> in instead of entirely calling them in order.

Could you describe your approach more fully? 

>
> Best regards,
> Leesoo

Re: [LSM Stacking] SELinux policy inside container affects a process on Host

[Dr. Greg]

On Fri, Jul 07, 2023 at 09:50:41AM -0700, Casey Schaufler wrote:

Hi, I hope the week is going well for everyone.

> On 7/7/2023 7:20 AM, Paul Moore wrote:
> > On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
> >> 2023-07-06 ?????? 10:43??? Paul Moore ???(???) ??? ???:
> >>> On Thu, Jul 6, 2023 at 1:20???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
> >>>  >
> >>>  > Hello! Here is another weird behavior of lsm stacking..
> >>>  >
> >>>  > test env
> >>>  > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38
> >>>  > - boot param: lsm=apparmor,selinux
> >>>  > - AppArmor (Host) + SELinux (LXD Container Fedora 36)
> >>>  >
> >>>  > In the test environment mentioned above and applying selinux policy
> >>>  > enforcing by running "setenforce 1" within the container, executing the
> >>>  > following command on the host will result in "Permission denied" output.
> >>>
> >>> SELinux operates independently of containers, or kernel namespacing in
> >>> general. When you load a SELinux policy it applies to all processes
> >>> on the system, regardless of where they are in relation to the process
> >>> which loaded the policy into the kernel.
> >>>
> >>> This behavior is independent of the LSM stacking work, you should be
> >>> able to see the same behavior even in cases where SELinux is the only
> >>> loaded LSM on the system.

> >> Thank you for the reply!
> >>
> >> So as far as I understand, the environment of LSM Stacking,
> >> AppArmor (Host) + SELinux (Container) couldn't provide features "using
> >> SELinux policy inside the container shouldn't affect to the host side"
> >> for now.
> >>
> >> If so, I wonder if you and Casey plan to design future features like
> >> that, because my co-workers and I are considering taking LSM stacking of
> >> AppArmor + SELinux in products that both policies must be working
> >> separately.

> > What you are looking for is a combination of LSM stacking and
> > individual LSM namespacing.  Sadly, I think the communications
> > around LSM stacking have not been very clear on this and I worry
> > that many people are going to be disappointed with LSM stacking
> > for this very reason.

> There have been many discussions regarding the viability of the
> using different LSM policies in containers. Some of these
> discussions have been quite lively. I have never claimed that LSM
> stacking addresses all of the possible use cases for multiple
> concurrent LSMs. If people are disappointed by how little they can
> accomplish with what is currently being proposed I can only say that
> we can't get on to the next phase until this work is complete.

It seems pretty clear, to us anyway, that generic user expectations
are that advanced security controls for Linux, ie beyond DAC, should
provide the same compartmentalization and isolation that other
resource namespaces bring to the table.  The 10 years of experience we
have had with building systems, and feedback we have received from
collaborators with significant experience in critical infrastructure,
drove the focus in TSEM on strictly partitioned and workload based
security controls.

We obviously had an advantage in that we came into this with the
opportunity for a clean design, whereas the existing, particularly
label based solutions, have the constraint of a single ground truth
with respect to the inode label implemented in the extended
attributes.  Which is the fault of nobody, but rather a function of
the fact that label based systems have a heritage from before anyone
even thought about resource namespaces.

Do to our objectives, and the approach we took, TSEM doesn't require
support for 'stacking' with other LSM's, obviously other LSM's do need
that support, not a criticism but an observation.  That opened the
door to implement what users would consider to be an independent
security namespace.

The take away, that I assume everyone interested in Linux security
would be in agreement on, perhaps not, is that user expectations are
to have independent and separately administered security control
environments that don't interact with one another.

> > While stacking of LSMs is largely done at the LSM layer, namespacing
> > LSMs such that they can be customized for individual containers
> > requires work to be done at the per-LSM level as each LSM is
> > different.  AppArmor already has a namespacing concept, but SELinux
> > does not.  Due to differences in the approach taken by the two LSMs,
> > namespacing is much more of a challenge for SELinux, largely due to
> > issues around filesystem labeling.  We have not given up on the idea,
> > but we have yet to arrive at a viable solution for namespacing
> > SELinux.

> I remain more optimistic than Paul about the options for supporting
> generic LSM namespacing. I hope to explore a couple notions that I
> have more fully, but as they depend on the current stacking work I
> may not get to them very soon.

I believe TSEM demonstrates that we already have the infrastructure at
the LSM layer for generic namespacing.  Of all the current LSM's, I
believe we have the most sophisticated namespace implementation with
respect to the functionality that it implements.

We have implemented TSEM using both the standard Linux namespace
infrastructure and as an independent namespace implementation using
the LSM 'blob' infrastructure.  FWIW, we have never looked back on the
decision to implement LSM specific namespacing using the generic LSM
'blob' functionality.

If there is a desire to provide some minimum level of generic security
namespace functionality I could recitate a whole list of thoughts to
consider but will leave that to another time.

> > If you are interested in stacking SELinux and AppArmor, I believe the
> > only practical solution is to run SELinux on the host system (initial
> > namespace) and run AppArmor in the containers.  Even in a world where
> > SELinux is fully namespaced, it would likely still be necessary to run
> > some type of SELinux policy on the host (initial namespace) in order
> > to support SELinux policies in the containers.

> SELinux policy is sufficiently flexible to support what would look
> like different policies on the host system and in the container. I
> think that the administration of such a system would be tricky, and
> the policy would be very complex, but it could be done, for some use
> cases at least.

These reflections illuminate our motivation in developing TSEM, others
may disagree, but a lot of experience in, and observation of, the
security industry has led us to believe that security has to get
simpler and easier to implement rather than more complex and arcane.

We are probably at an interesting juncture in Linux development.  The
security controls we make available as a platform can either pursue a
path where only highly skilled administrators and technology companies
can implement them, or, we can provide mechanisms that work to increase
the accessibility by development teams and ultimately the user
community to advanced security controls.

With TSEM, our design philosophy is that security controls need to
flow from the development process in order to accomplish this latter
objective.  CI/CD is now considered a necessary and standard practice
in the software industry, it doesn't seem like a stretch of the
imagination that security controls should flow from that process as
well.

One of the requirements of this model is the ability to strictly scope
security controls to the level of a workload nee security modeling
namespace.

Regardless of motivation, it would seem from this thread alone, that
there is a user expectation, if not a necessary technical requirement,
for Linux to provide infrastructure that enables strictly partitioned
and independent security controls that don't require extensive
reasoning as to what they might actually do in practice.

Have a good week.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity

Re: [LSM Stacking] SELinux policy inside container affects a process on Host

[Casey Schaufler]

On 7/18/2023 3:34 AM, Dr. Greg wrote:
> On Fri, Jul 07, 2023 at 09:50:41AM -0700, Casey Schaufler wrote:
>
> Hi, I hope the week is going well for everyone.
>
>> On 7/7/2023 7:20 AM, Paul Moore wrote:
>>> On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
>>>> 2023-07-06 ?????? 10:43??? Paul Moore ???(???) ??? ???:
>>>>> On Thu, Jul 6, 2023 at 1:20???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
>>>>>  >
>>>>>  > Hello! Here is another weird behavior of lsm stacking..
>>>>>  >
>>>>>  > test env
>>>>>  > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38
>>>>>  > - boot param: lsm=apparmor,selinux
>>>>>  > - AppArmor (Host) + SELinux (LXD Container Fedora 36)
>>>>>  >
>>>>>  > In the test environment mentioned above and applying selinux policy
>>>>>  > enforcing by running "setenforce 1" within the container, executing the
>>>>>  > following command on the host will result in "Permission denied" output.
>>>>>
>>>>> SELinux operates independently of containers, or kernel namespacing in
>>>>> general. When you load a SELinux policy it applies to all processes
>>>>> on the system, regardless of where they are in relation to the process
>>>>> which loaded the policy into the kernel.
>>>>>
>>>>> This behavior is independent of the LSM stacking work, you should be
>>>>> able to see the same behavior even in cases where SELinux is the only
>>>>> loaded LSM on the system.
>>>> Thank you for the reply!
>>>>
>>>> So as far as I understand, the environment of LSM Stacking,
>>>> AppArmor (Host) + SELinux (Container) couldn't provide features "using
>>>> SELinux policy inside the container shouldn't affect to the host side"
>>>> for now.
>>>>
>>>> If so, I wonder if you and Casey plan to design future features like
>>>> that, because my co-workers and I are considering taking LSM stacking of
>>>> AppArmor + SELinux in products that both policies must be working
>>>> separately.
>>> What you are looking for is a combination of LSM stacking and
>>> individual LSM namespacing.  Sadly, I think the communications
>>> around LSM stacking have not been very clear on this and I worry
>>> that many people are going to be disappointed with LSM stacking
>>> for this very reason.
>> There have been many discussions regarding the viability of the
>> using different LSM policies in containers. Some of these
>> discussions have been quite lively. I have never claimed that LSM
>> stacking addresses all of the possible use cases for multiple
>> concurrent LSMs. If people are disappointed by how little they can
>> accomplish with what is currently being proposed I can only say that
>> we can't get on to the next phase until this work is complete.
> It seems pretty clear, to us anyway, that generic user expectations
> are that advanced security controls for Linux, ie beyond DAC, should
> provide the same compartmentalization and isolation that other
> resource namespaces bring to the table.

It would have been really nice if the developers of resource namespaces
had addressed the "LSM question" when they created their schemes. But
they didn't. Namespaces are not primarily security constructs. You need
go no further than the group access problem of user namespaces to
understand where security ranks on the priority of namespaces.

>   The 10 years of experience we
> have had with building systems, and feedback we have received from
> collaborators with significant experience in critical infrastructure,
> drove the focus in TSEM on strictly partitioned and workload based
> security controls.

The 45 years of experience we have had with building systems at every
level from network appliances, through user interface engines and multi-level
secure supercomputers convince us that workload based controls can never
provide anything beyond grandiose security theater. We have often claimed that
isolation (partitioning, if you prefer) is easy, sharing is hard. Building
a system security policy based on alleged "safe" existing behavior is at best
naive.

>
> We obviously had an advantage in that we came into this with the
> opportunity for a clean design, whereas the existing, particularly
> label based solutions, have the constraint of a single ground truth
> with respect to the inode label implemented in the extended
> attributes.  Which is the fault of nobody, but rather a function of
> the fact that label based systems have a heritage from before anyone
> even thought about resource namespaces.

Resource namespaces are expensive and require extensive administration
to be useful. As one of the early developers of the inode label based
solutions you disparage so flippantly, I take umbrage with your
characterization of the design process. Of course we thought of features
which closely resemble user namespaces. They're great for isolation.
They're not so great for implementing fixed security policy, which was
the requirement and goal.

>
> Do to our objectives, and the approach we took, TSEM doesn't require
> support for 'stacking' with other LSM's, obviously other LSM's do need
> that support, not a criticism but an observation.  That opened the
> door to implement what users would consider to be an independent
> security namespace.
>
> The take away, that I assume everyone interested in Linux security
> would be in agreement on, perhaps not, is that user expectations are
> to have independent and separately administered security control
> environments that don't interact with one another.

So long as the "environments" are completely isolated this makes
perfect sense. What so many "users", and more importantly, software
snake oil salesmen, seem incapable of coming to grips with, is that
for an "environment" to be useful it is going to do some amount of
resource sharing with the host and frequently with other "environments".
That is where the lofty claims of isolation fall apart, and the real,
painful work for security developers, begins.


>>> While stacking of LSMs is largely done at the LSM layer, namespacing
>>> LSMs such that they can be customized for individual containers
>>> requires work to be done at the per-LSM level as each LSM is
>>> different.  AppArmor already has a namespacing concept, but SELinux
>>> does not.  Due to differences in the approach taken by the two LSMs,
>>> namespacing is much more of a challenge for SELinux, largely due to
>>> issues around filesystem labeling.  We have not given up on the idea,
>>> but we have yet to arrive at a viable solution for namespacing
>>> SELinux.
>> I remain more optimistic than Paul about the options for supporting
>> generic LSM namespacing. I hope to explore a couple notions that I
>> have more fully, but as they depend on the current stacking work I
>> may not get to them very soon.
> I believe TSEM demonstrates that we already have the infrastructure at
> the LSM layer for generic namespacing.  Of all the current LSM's, I
> believe we have the most sophisticated namespace implementation with
> respect to the functionality that it implements.
>
> We have implemented TSEM using both the standard Linux namespace
> infrastructure and as an independent namespace implementation using
> the LSM 'blob' infrastructure.  FWIW, we have never looked back on the
> decision to implement LSM specific namespacing using the generic LSM
> 'blob' functionality.
>
> If there is a desire to provide some minimum level of generic security
> namespace functionality I could recitate a whole list of thoughts to
> consider but will leave that to another time.

	I have discovered a truly marvelous patch for this, which this
	email is too brief to contain.

All kidding aside, there are a bunch of things we could do, but they all
introduce issues with object sharing.

>
>>> If you are interested in stacking SELinux and AppArmor, I believe the
>>> only practical solution is to run SELinux on the host system (initial
>>> namespace) and run AppArmor in the containers.  Even in a world where
>>> SELinux is fully namespaced, it would likely still be necessary to run
>>> some type of SELinux policy on the host (initial namespace) in order
>>> to support SELinux policies in the containers.
>> SELinux policy is sufficiently flexible to support what would look
>> like different policies on the host system and in the container. I
>> think that the administration of such a system would be tricky, and
>> the policy would be very complex, but it could be done, for some use
>> cases at least.
> These reflections illuminate our motivation in developing TSEM, others
> may disagree, but a lot of experience in, and observation of, the
> security industry has led us to believe that security has to get
> simpler and easier to implement rather than more complex and arcane.

Evidence would indicate this is an errant conclusion.

> We are probably at an interesting juncture in Linux development.  The
> security controls we make available as a platform can either pursue a
> path where only highly skilled administrators and technology companies
> can implement them, or, we can provide mechanisms that work to increase
> the accessibility by development teams and ultimately the user
> community to advanced security controls.

Ever hear of the "Hillbilly Hummer"? No, you don't leave security policy
development to end users.

>
> With TSEM, our design philosophy is that security controls need to
> flow from the development process in order to accomplish this latter
> objective.  CI/CD is now considered a necessary and standard practice
> in the software industry, it doesn't seem like a stretch of the
> imagination that security controls should flow from that process as
> well.
>
> One of the requirements of this model is the ability to strictly scope
> security controls to the level of a workload nee security modeling
> namespace.
>
> Regardless of motivation, it would seem from this thread alone, that
> there is a user expectation, if not a necessary technical requirement,
> for Linux to provide infrastructure that enables strictly partitioned
> and independent security controls that don't require extensive
> reasoning as to what they might actually do in practice.

You really have missed the point. By a long way. The problem of security
is not now, nor has it ever been, isolation. It is sharing. If it is
appropriate for "users" to determine sharing, we have mode bits. If it is
appropriate for "administrators" to determine sharing, we have mandatory
access controls and namespaces. If sharing is completely inappropriate,
we have virtualization.


>
> Have a good week.
>
> As always,
> Dr. Greg
>
> The Quixote Project - Flailing at the Travails of Cybersecurity

Re: [LSM Stacking] SELinux policy inside container affects a process on Host

[Dr. Greg]

On Tue, Jul 18, 2023 at 10:20:40AM -0700, Casey Schaufler wrote:

Good afternoon to everyone.

> On 7/18/2023 3:34 AM, Dr. Greg wrote:
> > On Fri, Jul 07, 2023 at 09:50:41AM -0700, Casey Schaufler wrote:
> >
> > Hi, I hope the week is going well for everyone.
> >
> >> On 7/7/2023 7:20 AM, Paul Moore wrote:
> >>> On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
> >>>> 2023-07-06 ?????? 10:43??? Paul Moore ???(???) ??? ???:
> >>>>> On Thu, Jul 6, 2023 at 1:20???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
> >>>>>  >
> >>>>>  > Hello! Here is another weird behavior of lsm stacking..
> >>>>>  >
> >>>>>  > test env
> >>>>>  > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38
> >>>>>  > - boot param: lsm=apparmor,selinux
> >>>>>  > - AppArmor (Host) + SELinux (LXD Container Fedora 36)
> >>>>>  >
> >>>>>  > In the test environment mentioned above and applying selinux policy
> >>>>>  > enforcing by running "setenforce 1" within the container, executing the
> >>>>>  > following command on the host will result in "Permission denied" output.
> >>>>>
> >>>>> SELinux operates independently of containers, or kernel namespacing in
> >>>>> general. When you load a SELinux policy it applies to all processes
> >>>>> on the system, regardless of where they are in relation to the process
> >>>>> which loaded the policy into the kernel.
> >>>>>
> >>>>> This behavior is independent of the LSM stacking work, you should be
> >>>>> able to see the same behavior even in cases where SELinux is the only
> >>>>> loaded LSM on the system.
> >>>> Thank you for the reply!
> >>>>
> >>>> So as far as I understand, the environment of LSM Stacking,
> >>>> AppArmor (Host) + SELinux (Container) couldn't provide features "using
> >>>> SELinux policy inside the container shouldn't affect to the host side"
> >>>> for now.
> >>>>
> >>>> If so, I wonder if you and Casey plan to design future features like
> >>>> that, because my co-workers and I are considering taking LSM stacking of
> >>>> AppArmor + SELinux in products that both policies must be working
> >>>> separately.
> >>> What you are looking for is a combination of LSM stacking and
> >>> individual LSM namespacing.  Sadly, I think the communications
> >>> around LSM stacking have not been very clear on this and I worry
> >>> that many people are going to be disappointed with LSM stacking
> >>> for this very reason.

> >> There have been many discussions regarding the viability of the
> >> using different LSM policies in containers. Some of these
> >> discussions have been quite lively. I have never claimed that LSM
> >> stacking addresses all of the possible use cases for multiple
> >> concurrent LSMs. If people are disappointed by how little they can
> >> accomplish with what is currently being proposed I can only say that
> >> we can't get on to the next phase until this work is complete.

> > It seems pretty clear, to us anyway, that generic user expectations
> > are that advanced security controls for Linux, ie beyond DAC, should
> > provide the same compartmentalization and isolation that other
> > resource namespaces bring to the table.

> It would have been really nice if the developers of resource
> namespaces had addressed the "LSM question" when they created their
> schemes. But they didn't. Namespaces are not primarily security
> constructs. You need go no further than the group access problem of
> user namespaces to understand where security ranks on the priority
> of namespaces.

It may very well be the case that namespaces are the worst abomination
that has ever been foisted on mankind with respect to security.

Unfortunately, that doesn't negate the fact that the software industry
has spoken and the notion of a 'container' or 'resource namespace',
whatever parlance one chooses to use, is now deeply ingrained in how
software is being developed and delivered and this will probably be
the case for the foreseeable future.

This thread was initiated by the fact that their is an expectation,
that will only grow in the future, that security controls can be
scoped to a subdivision less than that of an entire system and in a
manner that doesn't cause one security policy to interfere with or
complicate the implementation of another.

If current industry experience is any example, the one causing the
most problems will get turned off.  Or administrators will be left
trying to reason as to what security controls are actually being
achieved, which is always hazardous.

With respect to our work, if you believe that we are looking at a
namespace as an isolation concept you have misunderstand our
motivations, objectives and implementation.

The LSM infrastructure represents the basis set of information that
can be used to model the security behavior of a platform.  If it does
not, it cannot adequately enforce effective security controls, since
by definition, it would have insufficient visibility into all security
relevant behavior.

There are at least three ways this information can be used:

The LSM can be used to enforce a system wide security policy through
mandatory access controls, your area of interest and endeavor.

An equally valid concept is for developers to use this information
to verify that the security behavior of workloads that they develop
are consistent with what they desire.

A third possible use case of the LSM, since it represents access to
all of the information that describes the security state of a
platform, is to drive machine learning based analysis and
interpretation of the security status of a system.

The latter two use cases benefit from the ability to reduce the scope
and complexity of the model being analyzed, which is the intent of the
TSEM security modeling namespaces.

I'm just hazarding a guess here, no judgement implied, but I would
assume you view phenomenological modeling, machine learning and
artificial intelligence as irrelevant endeavors with respect to
security?

We have direct and constant dialogue with a group that has around 6000
virtual machines running 30,000+ containers at any given instant in
time.  Every VM is running, I believe, three CrowdStrike kernel
modules and other supportive infrastructure that are feeding 'machine
learning' telemetry into the cloud for security analysis.  I also
believe there are Kubernetes sidecars analysing container behavior in
the mix as well.

None of which is optional, given that the conversations surrounding
the technology consists of; "Run this because our insurance says we
have to".

The beauty in Linux is that you can ignore all of this and run
SeLinux, but to say that resoure namespaces, compartmentalization and
modeling are irrelevant, flies in the face of how security is being
done.

> > The 10 years of experience we have had with building systems, and
> > feedback we have received from collaborators with significant
> > experience in critical infrastructure, drove the focus in TSEM on
> > strictly partitioned and workload based security controls.

> The 45 years of experience we have had with building systems at
> every level from network appliances, through user interface engines
> and multi-level secure supercomputers convince us that workload
> based controls can never provide anything beyond grandiose security
> theater.
>
> We have often claimed that isolation (partitioning, if you prefer)
> is easy, sharing is hard. Building a system security policy based on
> alleged "safe" existing behavior is at best naive.

Personally, I've actually got two years on that, started with writing
assembler code to modify the functionality of RDOS running on Data
General Nova 2's, circa 1976.  Edited microcode to fix the 'tired
microcode' problems on DG Eclipses.  Even built and ran a
supercomputer center for about 6-7 years.  Spent a ton of time in the
last few years writing micro-controller code to implement hardware
Trusted Modeling Agents, so I think I've been full circle as well.

If we can put personal length issues aside, we can turn to the question
of security controls tuned to the needs of a workload.

Based on your comment above, I assume your position would be that
'Default deny, exception allow' security policies are inadequate or
unsafe?

There is probably no use drilling down too much further into technical
details until we can reach that point of understanding.

> > We obviously had an advantage in that we came into this with the
> > opportunity for a clean design, whereas the existing, particularly
> > label based solutions, have the constraint of a single ground truth
> > with respect to the inode label implemented in the extended
> > attributes.  Which is the fault of nobody, but rather a function of
> > the fact that label based systems have a heritage from before anyone
> > even thought about resource namespaces.

> Resource namespaces are expensive and require extensive administration
> to be useful. As one of the early developers of the inode label based
> solutions you disparage so flippantly, I take umbrage with your
> characterization of the design process.
>
> Of course we thought of features which closely resemble user
> namespaces. They're great for isolation.  They're not so great for
> implementing fixed security policy, which was the requirement and
> goal.

I wasn't being flippant or disparaging, please do not suggest malign
intent where it does not exist.

I will stand informed that you and others considered the notion of
something equivalent to Linux namespaces or workloads and discarded
them as useless, perhaps for very good reasons given the objectives you
were attempting to achieve.

Perhaps, unforunately, the rest of the world has gone in a different
direction and now has expectations and needs that are influenced by
the road that was chosen.

Two comments:

I find your observation that resource namespaces are expensive
interesting.  While they may not provide the degree of isolation you
are interested in, one of the issues that drove their adoption was
some degree of isolation with lower overhead than full virtualization.

Secondly, I believe that an unjaded observer would not consider TSEM
security modeling namespaces to require complex administrative
overhead.  Is there something about the usage examples and/or their
description in the documentation that suggests the degree of
complexity required to use them even approaches that of an OCI
orchestrator?

> > Do to our objectives, and the approach we took, TSEM doesn't require
> > support for 'stacking' with other LSM's, obviously other LSM's do need
> > that support, not a criticism but an observation.  That opened the
> > door to implement what users would consider to be an independent
> > security namespace.
> >
> > The take away, that I assume everyone interested in Linux security
> > would be in agreement on, perhaps not, is that user expectations are
> > to have independent and separately administered security control
> > environments that don't interact with one another.

> So long as the "environments" are completely isolated this makes
> perfect sense. What so many "users", and more importantly, software
> snake oil salesmen, seem incapable of coming to grips with, is that
> for an "environment" to be useful it is going to do some amount of
> resource sharing with the host and frequently with other
> "environments".  That is where the lofty claims of isolation fall
> apart, and the real, painful work for security developers, begins.

First, we are not selling anything, we are attempting to contribute
infrastructure to the common good to implement a security model that
we have worked to significantly document the rationale for.

Once again, TSEM 'namespaces' are not a mechanism for imposing
isolation, they are about limiting the scope of acceptable security
behaviors that can be exhibited by a process heirarchy.

This allows a development team to impose a requirement that the
workload block, through the use of mandatory controls, any security
behavior that the application has not been unit tested to, without the
need to engage systems administration support.

Since the behaviors are workload specific there is less opportunity
for the controls to 'break' the application.  Which, based on our
reasonably significant field experience and depending on the
environment, results in an order being given to turn off the controls.

None of this limits the ability of the system administrators to impose
more rigid controls in pursuit of a whole system security policy if
that is a desired goal of the architecture.

With respect to modeling of security behavior, a namespace is a
mechanism for reducing model complexity, which in turn increases the
accuracy of the model prediction.

If one doubts the importance of this concept in the modern enterprise
security environment, I can go into stories about running uname, on a
Linux box running an Oracle database implementation, setting off
security policy alarms that bring in the security team and the need to
write a formal security violation explanation.

If there would be interest, I can post a link to a reasonably current
review paper on the application of machine learning to system call
analysis for Host Intrusion and Anomaly detection.  It specifically
calls out the need to focus on driving the model at workload scope in
order to increase prediction accuracy.

One of the forward looking objectives of TSEM namespaces is to drive
models from the LSM level that, again by definition, has the most
complete visibility into the security state of the system.

> >>> While stacking of LSMs is largely done at the LSM layer, namespacing
> >>> LSMs such that they can be customized for individual containers
> >>> requires work to be done at the per-LSM level as each LSM is
> >>> different.  AppArmor already has a namespacing concept, but SELinux
> >>> does not.  Due to differences in the approach taken by the two LSMs,
> >>> namespacing is much more of a challenge for SELinux, largely due to
> >>> issues around filesystem labeling.  We have not given up on the idea,
> >>> but we have yet to arrive at a viable solution for namespacing
> >>> SELinux.

> >> I remain more optimistic than Paul about the options for
> >> supporting generic LSM namespacing. I hope to explore a couple
> >> notions that I have more fully, but as they depend on the current
> >> stacking work I may not get to them very soon.

> > I believe TSEM demonstrates that we already have the
> > infrastructure at the LSM layer for generic namespacing.  Of all
> > the current LSM's, I believe we have the most sophisticated
> > namespace implementation with respect to the functionality that it
> > implements.
> >
> > We have implemented TSEM using both the standard Linux namespace
> > infrastructure and as an independent namespace implementation using
> > the LSM 'blob' infrastructure.  FWIW, we have never looked back on the
> > decision to implement LSM specific namespacing using the generic LSM
> > 'blob' functionality.
> >
> > If there is a desire to provide some minimum level of generic security
> > namespace functionality I could recitate a whole list of thoughts to
> > consider but will leave that to another time.

> 	I have discovered a truly marvelous patch for this, which this
> 	email is too brief to contain.
>
> All kidding aside, there are a bunch of things we could do, but they all
> introduce issues with object sharing.

We have a TMA model implementation, that reads the SeLinux extended
security attribute and role information and uses those in the
computation of the allowed security state coefficients that would be
representative of the MAC status of a workload.  The TSEM
documentation discusses the relationship between security state
coefficients and positive AVC nodes in the 'Security Event Modeling'
section, starting at line 204.

My comments would have been framed around the experience and insights
that work gave us with respect to the challenges associated with label
based object sharing and possible responses to those issues that TSEM
would facilitate.

We don't blow smoke, but we are sensitive to the fact that people
don't like to read much anymore.

> >>> If you are interested in stacking SELinux and AppArmor, I believe the
> >>> only practical solution is to run SELinux on the host system (initial
> >>> namespace) and run AppArmor in the containers.  Even in a world where
> >>> SELinux is fully namespaced, it would likely still be necessary to run
> >>> some type of SELinux policy on the host (initial namespace) in order
> >>> to support SELinux policies in the containers.

> >> SELinux policy is sufficiently flexible to support what would look
> >> like different policies on the host system and in the container. I
> >> think that the administration of such a system would be tricky, and
> >> the policy would be very complex, but it could be done, for some use
> >> cases at least.

> > These reflections illuminate our motivation in developing TSEM, others
> > may disagree, but a lot of experience in, and observation of, the
> > security industry has led us to believe that security has to get
> > simpler and easier to implement rather than more complex and arcane.

> Evidence would indicate this is an errant conclusion.

Interesting.

So, by extentive reasoning, if we make security more complex, arcane
and brittle; in an environment where professional security experience
is increasingly limited, our systems will become more secure?

I guess history will judge.

> > We are probably at an interesting juncture in Linux development.  The
> > security controls we make available as a platform can either pursue a
> > path where only highly skilled administrators and technology companies
> > can implement them, or, we can provide mechanisms that work to increase
> > the accessibility by development teams and ultimately the user
> > community to advanced security controls.

> Ever hear of the "Hillbilly Hummer"? No, you don't leave security
> policy development to end users.

No, the only Hillbilly thing we have here is a guy on the lake who has
two 4x8 sheets of green treated plywood nailed together with 50 gallon
plastic barrels on each corner pushed around by a five horse Evinrude.

More directly to your point, you're misrepresenting our intentions, we
are not suggesting we leave it to end users.

As noted above, we have pretty solid feedback from groups who are
deeply involved with infrastructure security that believe there are
positive benefits to development teams being able to independently
verify and protect the security of their workloads.

If this works to increase the security posture of the systems in
question, end users of the service would obviously seem to benefit.

> > With TSEM, our design philosophy is that security controls need to
> > flow from the development process in order to accomplish this latter
> > objective.  CI/CD is now considered a necessary and standard practice
> > in the software industry, it doesn't seem like a stretch of the
> > imagination that security controls should flow from that process as
> > well.
> >
> > One of the requirements of this model is the ability to strictly scope
> > security controls to the level of a workload nee security modeling
> > namespace.
> >
> > Regardless of motivation, it would seem from this thread alone, that
> > there is a user expectation, if not a necessary technical requirement,
> > for Linux to provide infrastructure that enables strictly partitioned
> > and independent security controls that don't require extensive
> > reasoning as to what they might actually do in practice.

> You really have missed the point. By a long way. The problem of
> security is not now, nor has it ever been, isolation. It is
> sharing. If it is appropriate for "users" to determine sharing, we
> have mode bits. If it is appropriate for "administrators" to
> determine sharing, we have mandatory access controls and
> namespaces. If sharing is completely inappropriate, we have
> virtualization.

Hopefully, if people have elected to read this far, they will at least
entertain the notion that our efforts are not as witless as has been
suggested.

Every technical issue involves shades of grey but TSEM is not about
isolation, or sharing, for that matter.  It is about defining whether
or not a workload is acting consistently with what it was designed and
intended to do and either acting in response or signaling that fact to
others, in as precise a manner as can be implemented.

It attempts to do this in what is, at least currently, within the
context of the technology framework that industry has chosen to
operate in.  This of course leaves open the question if industry has
chosen properly, which is something that neither one of us is going to
do anything about.

Best wishes for a productive remainder of the week.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity

Re: [LSM Stacking] SELinux policy inside container affects a process on Host

[Casey Schaufler]

On 7/19/2023 11:45 AM, Dr. Greg wrote:
> On Tue, Jul 18, 2023 at 10:20:40AM -0700, Casey Schaufler wrote:
>
> Good afternoon to everyone.
>
>> On 7/18/2023 3:34 AM, Dr. Greg wrote:
>>> On Fri, Jul 07, 2023 at 09:50:41AM -0700, Casey Schaufler wrote:
>>>
>>> Hi, I hope the week is going well for everyone.
>>>
>>>> On 7/7/2023 7:20 AM, Paul Moore wrote:
>>>>> On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
>>>>>> 2023-07-06 ?????? 10:43??? Paul Moore ???(???) ??? ???:
>>>>>>> On Thu, Jul 6, 2023 at 1:20???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
>>>>>>>  >
>>>>>>>  > Hello! Here is another weird behavior of lsm stacking..
>>>>>>>  >
>>>>>>>  > test env
>>>>>>>  > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38
>>>>>>>  > - boot param: lsm=apparmor,selinux
>>>>>>>  > - AppArmor (Host) + SELinux (LXD Container Fedora 36)
>>>>>>>  >
>>>>>>>  > In the test environment mentioned above and applying selinux policy
>>>>>>>  > enforcing by running "setenforce 1" within the container, executing the
>>>>>>>  > following command on the host will result in "Permission denied" output.
>>>>>>>
>>>>>>> SELinux operates independently of containers, or kernel namespacing in
>>>>>>> general. When you load a SELinux policy it applies to all processes
>>>>>>> on the system, regardless of where they are in relation to the process
>>>>>>> which loaded the policy into the kernel.
>>>>>>>
>>>>>>> This behavior is independent of the LSM stacking work, you should be
>>>>>>> able to see the same behavior even in cases where SELinux is the only
>>>>>>> loaded LSM on the system.
>>>>>> Thank you for the reply!
>>>>>>
>>>>>> So as far as I understand, the environment of LSM Stacking,
>>>>>> AppArmor (Host) + SELinux (Container) couldn't provide features "using
>>>>>> SELinux policy inside the container shouldn't affect to the host side"
>>>>>> for now.
>>>>>>
>>>>>> If so, I wonder if you and Casey plan to design future features like
>>>>>> that, because my co-workers and I are considering taking LSM stacking of
>>>>>> AppArmor + SELinux in products that both policies must be working
>>>>>> separately.
>>>>> What you are looking for is a combination of LSM stacking and
>>>>> individual LSM namespacing.  Sadly, I think the communications
>>>>> around LSM stacking have not been very clear on this and I worry
>>>>> that many people are going to be disappointed with LSM stacking
>>>>> for this very reason.
>>>> There have been many discussions regarding the viability of the
>>>> using different LSM policies in containers. Some of these
>>>> discussions have been quite lively. I have never claimed that LSM
>>>> stacking addresses all of the possible use cases for multiple
>>>> concurrent LSMs. If people are disappointed by how little they can
>>>> accomplish with what is currently being proposed I can only say that
>>>> we can't get on to the next phase until this work is complete.
>>> It seems pretty clear, to us anyway, that generic user expectations
>>> are that advanced security controls for Linux, ie beyond DAC, should
>>> provide the same compartmentalization and isolation that other
>>> resource namespaces bring to the table.
>> It would have been really nice if the developers of resource
>> namespaces had addressed the "LSM question" when they created their
>> schemes. But they didn't. Namespaces are not primarily security
>> constructs. You need go no further than the group access problem of
>> user namespaces to understand where security ranks on the priority
>> of namespaces.
> It may very well be the case that namespaces are the worst abomination
> that has ever been foisted on mankind with respect to security.

Oh heavens, no. There are many things that are much worse.

>
> Unfortunately, that doesn't negate the fact that the software industry
> has spoken and the notion of a 'container' or 'resource namespace',
> whatever parlance one chooses to use, is now deeply ingrained in how
> software is being developed and delivered and this will probably be
> the case for the foreseeable future.

Containers are a fad, like grid computing, Beowulf clusters and
storage area networks.

> This thread was initiated by the fact that their is an expectation,
> that will only grow in the future, that security controls can be
> scoped to a subdivision less than that of an entire system and in a
> manner that doesn't cause one security policy to interfere with or
> complicate the implementation of another.

I dispute your "fact". I understand that some people believe that,
but I also know that they haven't been told to expect that, at least
not by the developers who are in a position to make it happen.

> If current industry experience is any example, the one causing the
> most problems will get turned off.  Or administrators will be left
> trying to reason as to what security controls are actually being
> achieved, which is always hazardous.

<snark - sorry>
Horror of horrors! Users have no business understanding the security
policy their system implements! You may as well let them write their
own programs!
</snark - sorry>

>
> With respect to our work, if you believe that we are looking at a
> namespace as an isolation concept you have misunderstand our
> motivations, objectives and implementation.
>
> The LSM infrastructure represents the basis set of information that
> can be used to model the security behavior of a platform.  If it does
> not, it cannot adequately enforce effective security controls, since
> by definition, it would have insufficient visibility into all security
> relevant behavior.

You have it backwards. The LSM infrastructure is driven by the needs
of the security modules. If no one needed a hook for bind() we wouldn't
have one.

>
> There are at least three ways this information can be used:
>
> The LSM can be used to enforce a system wide security policy through
> mandatory access controls, your area of interest and endeavor.

MAC has been an area of interest of mine for a long time,
but is hardly the only one. Unfortunately, the other things
I want to do require stackability. They don't require either/or
with SELinux (or AppArmor, or Smack) but they do use cred blobs. 

> An equally valid concept is for developers to use this information
> to verify that the security behavior of workloads that they develop
> are consistent with what they desire.

Err, no. That assumes that the information is sufficiently complete to
identify any possible interesting behavior. There's no way I would
claim the LSM infrastructure provides that.

> A third possible use case of the LSM, since it represents access to
> all of the information that describes the security state of a
> platform, is to drive machine learning based analysis and
> interpretation of the security status of a system.

Nope. The claim that LSM provides access to "all of the information"
is fallacious. It provides access to the information that existing
security modules have asked for, and no more.

> The latter two use cases benefit from the ability to reduce the scope
> and complexity of the model being analyzed, which is the intent of the
> TSEM security modeling namespaces.
>
> I'm just hazarding a guess here, no judgement implied, but I would
> assume you view phenomenological modeling, machine learning and
> artificial intelligence as irrelevant endeavors with respect to
> security?

Oh no, They are likely to be very relevant. Alas, I don't expect the
general populous to listen to Artificial intelligence any better than
they listen to Natural intelligence. I fully expect AI to provide
significant insights, but the audience will be the security community,
not the user community. 

> We have direct and constant dialogue with a group that has around 6000
> virtual machines running 30,000+ containers at any given instant in
> time.  Every VM is running, I believe, three CrowdStrike kernel
> modules and other supportive infrastructure that are feeding 'machine
> learning' telemetry into the cloud for security analysis.  I also
> believe there are Kubernetes sidecars analysing container behavior in
> the mix as well.

What is the AI looking for? How do you know if it is "security" you're
analyzing, as opposed to teen-age buying patterns?

> None of which is optional, given that the conversations surrounding
> the technology consists of; "Run this because our insurance says we
> have to".
>
> The beauty in Linux is that you can ignore all of this and run
> SeLinux, but to say that resoure namespaces, compartmentalization and
> modeling are irrelevant, flies in the face of how security is being
> done.

I often see cases where someone tries to implement a secure behavior
using sophisticated mechanisms when a simple mechanism intended to
address that specific issue is already in the system. That point that
lots of people are using these mechanisms is valid, but in way too
many cases far from the easiest or most reliable way to go about solving
the problem.

>
>>> The 10 years of experience we have had with building systems, and
>>> feedback we have received from collaborators with significant
>>> experience in critical infrastructure, drove the focus in TSEM on
>>> strictly partitioned and workload based security controls.
>> The 45 years of experience we have had with building systems at
>> every level from network appliances, through user interface engines
>> and multi-level secure supercomputers convince us that workload
>> based controls can never provide anything beyond grandiose security
>> theater.
>>
>> We have often claimed that isolation (partitioning, if you prefer)
>> is easy, sharing is hard. Building a system security policy based on
>> alleged "safe" existing behavior is at best naive.
> Personally, I've actually got two years on that, started with writing
> assembler code to modify the functionality of RDOS running on Data
> General Nova 2's, circa 1976.  Edited microcode to fix the 'tired
> microcode' problems on DG Eclipses.  Even built and ran a
> supercomputer center for about 6-7 years.  Spent a ton of time in the
> last few years writing micro-controller code to implement hardware
> Trusted Modeling Agents, so I think I've been full circle as well.
>
> If we can put personal length issues aside, we can turn to the question
> of security controls tuned to the needs of a workload.
>
> Based on your comment above, I assume your position would be that
> 'Default deny, exception allow' security policies are inadequate or
> unsafe?

They are certainly prone to a particular kind of error. Program A accesses
resource B, and the "policy" author doesn't know why. Rather than researching
the reason that A accesses B, the policy is written to allow the access on
the basis that A needs the access to do its job. Alas, giving A access to B
also gives A access to C, which allows A to do nefarious things. Because no
one ever contemplated the relationship between B and C, and A doesn't normally
access C, the "policy" is flawed.

... And that's all I have time for today.

>
> There is probably no use drilling down too much further into technical
> details until we can reach that point of understanding.
>
>>> We obviously had an advantage in that we came into this with the
>>> opportunity for a clean design, whereas the existing, particularly
>>> label based solutions, have the constraint of a single ground truth
>>> with respect to the inode label implemented in the extended
>>> attributes.  Which is the fault of nobody, but rather a function of
>>> the fact that label based systems have a heritage from before anyone
>>> even thought about resource namespaces.
>> Resource namespaces are expensive and require extensive administration
>> to be useful. As one of the early developers of the inode label based
>> solutions you disparage so flippantly, I take umbrage with your
>> characterization of the design process.
>>
>> Of course we thought of features which closely resemble user
>> namespaces. They're great for isolation.  They're not so great for
>> implementing fixed security policy, which was the requirement and
>> goal.
> I wasn't being flippant or disparaging, please do not suggest malign
> intent where it does not exist.
>
> I will stand informed that you and others considered the notion of
> something equivalent to Linux namespaces or workloads and discarded
> them as useless, perhaps for very good reasons given the objectives you
> were attempting to achieve.
>
> Perhaps, unforunately, the rest of the world has gone in a different
> direction and now has expectations and needs that are influenced by
> the road that was chosen.
>
> Two comments:
>
> I find your observation that resource namespaces are expensive
> interesting.  While they may not provide the degree of isolation you
> are interested in, one of the issues that drove their adoption was
> some degree of isolation with lower overhead than full virtualization.
>
> Secondly, I believe that an unjaded observer would not consider TSEM
> security modeling namespaces to require complex administrative
> overhead.  Is there something about the usage examples and/or their
> description in the documentation that suggests the degree of
> complexity required to use them even approaches that of an OCI
> orchestrator?
>
>>> Do to our objectives, and the approach we took, TSEM doesn't require
>>> support for 'stacking' with other LSM's, obviously other LSM's do need
>>> that support, not a criticism but an observation.  That opened the
>>> door to implement what users would consider to be an independent
>>> security namespace.
>>>
>>> The take away, that I assume everyone interested in Linux security
>>> would be in agreement on, perhaps not, is that user expectations are
>>> to have independent and separately administered security control
>>> environments that don't interact with one another.
>> So long as the "environments" are completely isolated this makes
>> perfect sense. What so many "users", and more importantly, software
>> snake oil salesmen, seem incapable of coming to grips with, is that
>> for an "environment" to be useful it is going to do some amount of
>> resource sharing with the host and frequently with other
>> "environments".  That is where the lofty claims of isolation fall
>> apart, and the real, painful work for security developers, begins.
> First, we are not selling anything, we are attempting to contribute
> infrastructure to the common good to implement a security model that
> we have worked to significantly document the rationale for.
>
> Once again, TSEM 'namespaces' are not a mechanism for imposing
> isolation, they are about limiting the scope of acceptable security
> behaviors that can be exhibited by a process heirarchy.
>
> This allows a development team to impose a requirement that the
> workload block, through the use of mandatory controls, any security
> behavior that the application has not been unit tested to, without the
> need to engage systems administration support.
>
> Since the behaviors are workload specific there is less opportunity
> for the controls to 'break' the application.  Which, based on our
> reasonably significant field experience and depending on the
> environment, results in an order being given to turn off the controls.
>
> None of this limits the ability of the system administrators to impose
> more rigid controls in pursuit of a whole system security policy if
> that is a desired goal of the architecture.
>
> With respect to modeling of security behavior, a namespace is a
> mechanism for reducing model complexity, which in turn increases the
> accuracy of the model prediction.
>
> If one doubts the importance of this concept in the modern enterprise
> security environment, I can go into stories about running uname, on a
> Linux box running an Oracle database implementation, setting off
> security policy alarms that bring in the security team and the need to
> write a formal security violation explanation.
>
> If there would be interest, I can post a link to a reasonably current
> review paper on the application of machine learning to system call
> analysis for Host Intrusion and Anomaly detection.  It specifically
> calls out the need to focus on driving the model at workload scope in
> order to increase prediction accuracy.
>
> One of the forward looking objectives of TSEM namespaces is to drive
> models from the LSM level that, again by definition, has the most
> complete visibility into the security state of the system.
>
>>>>> While stacking of LSMs is largely done at the LSM layer, namespacing
>>>>> LSMs such that they can be customized for individual containers
>>>>> requires work to be done at the per-LSM level as each LSM is
>>>>> different.  AppArmor already has a namespacing concept, but SELinux
>>>>> does not.  Due to differences in the approach taken by the two LSMs,
>>>>> namespacing is much more of a challenge for SELinux, largely due to
>>>>> issues around filesystem labeling.  We have not given up on the idea,
>>>>> but we have yet to arrive at a viable solution for namespacing
>>>>> SELinux.
>>>> I remain more optimistic than Paul about the options for
>>>> supporting generic LSM namespacing. I hope to explore a couple
>>>> notions that I have more fully, but as they depend on the current
>>>> stacking work I may not get to them very soon.
>>> I believe TSEM demonstrates that we already have the
>>> infrastructure at the LSM layer for generic namespacing.  Of all
>>> the current LSM's, I believe we have the most sophisticated
>>> namespace implementation with respect to the functionality that it
>>> implements.
>>>
>>> We have implemented TSEM using both the standard Linux namespace
>>> infrastructure and as an independent namespace implementation using
>>> the LSM 'blob' infrastructure.  FWIW, we have never looked back on the
>>> decision to implement LSM specific namespacing using the generic LSM
>>> 'blob' functionality.
>>>
>>> If there is a desire to provide some minimum level of generic security
>>> namespace functionality I could recitate a whole list of thoughts to
>>> consider but will leave that to another time.
>> 	I have discovered a truly marvelous patch for this, which this
>> 	email is too brief to contain.
>>
>> All kidding aside, there are a bunch of things we could do, but they all
>> introduce issues with object sharing.
> We have a TMA model implementation, that reads the SeLinux extended
> security attribute and role information and uses those in the
> computation of the allowed security state coefficients that would be
> representative of the MAC status of a workload.  The TSEM
> documentation discusses the relationship between security state
> coefficients and positive AVC nodes in the 'Security Event Modeling'
> section, starting at line 204.
>
> My comments would have been framed around the experience and insights
> that work gave us with respect to the challenges associated with label
> based object sharing and possible responses to those issues that TSEM
> would facilitate.
>
> We don't blow smoke, but we are sensitive to the fact that people
> don't like to read much anymore.
>
>>>>> If you are interested in stacking SELinux and AppArmor, I believe the
>>>>> only practical solution is to run SELinux on the host system (initial
>>>>> namespace) and run AppArmor in the containers.  Even in a world where
>>>>> SELinux is fully namespaced, it would likely still be necessary to run
>>>>> some type of SELinux policy on the host (initial namespace) in order
>>>>> to support SELinux policies in the containers.
>>>> SELinux policy is sufficiently flexible to support what would look
>>>> like different policies on the host system and in the container. I
>>>> think that the administration of such a system would be tricky, and
>>>> the policy would be very complex, but it could be done, for some use
>>>> cases at least.
>>> These reflections illuminate our motivation in developing TSEM, others
>>> may disagree, but a lot of experience in, and observation of, the
>>> security industry has led us to believe that security has to get
>>> simpler and easier to implement rather than more complex and arcane.
>> Evidence would indicate this is an errant conclusion.
> Interesting.
>
> So, by extentive reasoning, if we make security more complex, arcane
> and brittle; in an environment where professional security experience
> is increasingly limited, our systems will become more secure?
>
> I guess history will judge.
>
>>> We are probably at an interesting juncture in Linux development.  The
>>> security controls we make available as a platform can either pursue a
>>> path where only highly skilled administrators and technology companies
>>> can implement them, or, we can provide mechanisms that work to increase
>>> the accessibility by development teams and ultimately the user
>>> community to advanced security controls.
>> Ever hear of the "Hillbilly Hummer"? No, you don't leave security
>> policy development to end users.
> No, the only Hillbilly thing we have here is a guy on the lake who has
> two 4x8 sheets of green treated plywood nailed together with 50 gallon
> plastic barrels on each corner pushed around by a five horse Evinrude.
>
> More directly to your point, you're misrepresenting our intentions, we
> are not suggesting we leave it to end users.
>
> As noted above, we have pretty solid feedback from groups who are
> deeply involved with infrastructure security that believe there are
> positive benefits to development teams being able to independently
> verify and protect the security of their workloads.
>
> If this works to increase the security posture of the systems in
> question, end users of the service would obviously seem to benefit.
>
>>> With TSEM, our design philosophy is that security controls need to
>>> flow from the development process in order to accomplish this latter
>>> objective.  CI/CD is now considered a necessary and standard practice
>>> in the software industry, it doesn't seem like a stretch of the
>>> imagination that security controls should flow from that process as
>>> well.
>>>
>>> One of the requirements of this model is the ability to strictly scope
>>> security controls to the level of a workload nee security modeling
>>> namespace.
>>>
>>> Regardless of motivation, it would seem from this thread alone, that
>>> there is a user expectation, if not a necessary technical requirement,
>>> for Linux to provide infrastructure that enables strictly partitioned
>>> and independent security controls that don't require extensive
>>> reasoning as to what they might actually do in practice.
>> You really have missed the point. By a long way. The problem of
>> security is not now, nor has it ever been, isolation. It is
>> sharing. If it is appropriate for "users" to determine sharing, we
>> have mode bits. If it is appropriate for "administrators" to
>> determine sharing, we have mandatory access controls and
>> namespaces. If sharing is completely inappropriate, we have
>> virtualization.
> Hopefully, if people have elected to read this far, they will at least
> entertain the notion that our efforts are not as witless as has been
> suggested.
>
> Every technical issue involves shades of grey but TSEM is not about
> isolation, or sharing, for that matter.  It is about defining whether
> or not a workload is acting consistently with what it was designed and
> intended to do and either acting in response or signaling that fact to
> others, in as precise a manner as can be implemented.
>
> It attempts to do this in what is, at least currently, within the
> context of the technology framework that industry has chosen to
> operate in.  This of course leaves open the question if industry has
> chosen properly, which is something that neither one of us is going to
> do anything about.
>
> Best wishes for a productive remainder of the week.
>
> As always,
> Dr. Greg
>
> The Quixote Project - Flailing at the Travails of Cybersecurity

Re: [LSM Stacking] SELinux policy inside container affects a process on Host

[Dr. Greg]

On Wed, Jul 19, 2023 at 05:21:37PM -0700, Casey Schaufler wrote:

I hope the week is ending well for everyone.

> On 7/19/2023 11:45 AM, Dr. Greg wrote:
> > On Tue, Jul 18, 2023 at 10:20:40AM -0700, Casey Schaufler wrote:
> >
> > Good afternoon to everyone.
> >
> >> On 7/18/2023 3:34 AM, Dr. Greg wrote:
> >>> On Fri, Jul 07, 2023 at 09:50:41AM -0700, Casey Schaufler wrote:
> >>>
> >>> Hi, I hope the week is going well for everyone.
> >>>
> >>>> On 7/7/2023 7:20 AM, Paul Moore wrote:
> >>>>> On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
> >>>>>> 2023-07-06 ?????? 10:43??? Paul Moore ???(???) ??? ???:
> >>>>>>> On Thu, Jul 6, 2023 at 1:20???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
> >>>>>>>  >
> >>>>>>>  > Hello! Here is another weird behavior of lsm stacking..
> >>>>>>>  >
> >>>>>>>  > test env
> >>>>>>>  > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38
> >>>>>>>  > - boot param: lsm=apparmor,selinux
> >>>>>>>  > - AppArmor (Host) + SELinux (LXD Container Fedora 36)
> >>>>>>>  >
> >>>>>>>  > In the test environment mentioned above and applying selinux policy
> >>>>>>>  > enforcing by running "setenforce 1" within the container, executing the
> >>>>>>>  > following command on the host will result in "Permission denied" output.
> >>>>>>>
> >>>>>>> SELinux operates independently of containers, or kernel namespacing in
> >>>>>>> general. When you load a SELinux policy it applies to all processes
> >>>>>>> on the system, regardless of where they are in relation to the process
> >>>>>>> which loaded the policy into the kernel.
> >>>>>>>
> >>>>>>> This behavior is independent of the LSM stacking work, you should be
> >>>>>>> able to see the same behavior even in cases where SELinux is the only
> >>>>>>> loaded LSM on the system.
> >>>>>> Thank you for the reply!
> >>>>>>
> >>>>>> So as far as I understand, the environment of LSM Stacking,
> >>>>>> AppArmor (Host) + SELinux (Container) couldn't provide features "using
> >>>>>> SELinux policy inside the container shouldn't affect to the host side"
> >>>>>> for now.
> >>>>>>
> >>>>>> If so, I wonder if you and Casey plan to design future features like
> >>>>>> that, because my co-workers and I are considering taking LSM stacking of
> >>>>>> AppArmor + SELinux in products that both policies must be working
> >>>>>> separately.
> >>>>> What you are looking for is a combination of LSM stacking and
> >>>>> individual LSM namespacing.  Sadly, I think the communications
> >>>>> around LSM stacking have not been very clear on this and I worry
> >>>>> that many people are going to be disappointed with LSM stacking
> >>>>> for this very reason.
> >>>> There have been many discussions regarding the viability of the
> >>>> using different LSM policies in containers. Some of these
> >>>> discussions have been quite lively. I have never claimed that LSM
> >>>> stacking addresses all of the possible use cases for multiple
> >>>> concurrent LSMs. If people are disappointed by how little they can
> >>>> accomplish with what is currently being proposed I can only say that
> >>>> we can't get on to the next phase until this work is complete.
> >>> It seems pretty clear, to us anyway, that generic user expectations
> >>> are that advanced security controls for Linux, ie beyond DAC, should
> >>> provide the same compartmentalization and isolation that other
> >>> resource namespaces bring to the table.
> >> It would have been really nice if the developers of resource
> >> namespaces had addressed the "LSM question" when they created their
> >> schemes. But they didn't. Namespaces are not primarily security
> >> constructs. You need go no further than the group access problem of
> >> user namespaces to understand where security ranks on the priority
> >> of namespaces.

> > It may very well be the case that namespaces are the worst abomination
> > that has ever been foisted on mankind with respect to security.

> Oh heavens, no. There are many things that are much worse.

Noted with interest, hopefully none of it is inside of Linux.

> > Unfortunately, that doesn't negate the fact that the software industry
> > has spoken and the notion of a 'container' or 'resource namespace',
> > whatever parlance one chooses to use, is now deeply ingrained in how
> > software is being developed and delivered and this will probably be
> > the case for the foreseeable future.

> Containers are a fad, like grid computing, Beowulf clusters and
> storage area networks.

Interesting outlook.

FWIW, on a strictly unrelated, non-technical front.

My Dad is telling me the same thing, almost every day, about these
automatic transmissions they are putting in cars.  I'm hoping that
what he thinks comes true before I have lost all the acumen that I
developed double-clutching a 3-5-5 triple split Fuller LoadRanger on
the tail of the 3208 Cat that I spent a fair amount of time driving,
during a decidedly non-technical interlude in my professional career.

The above offered, as a public service to any interests, who feel that
TSEM shouldn't see the light of day because it, proudly,
originates from what are decidedly hillbilly origins... :-)

Besides security, it looks like I also personally fail, on a secondary
technical front.  I architected, designed and direct the maintenance
over a pretty good sized SAN, that has been steadily advancing over
the last 23 years since it was first built.  It currently links three
geographically dispersed data-centers at 32 GBPS storage target speeds
to synchronously replicate petabytes of data on a day in and data out
basis.  Not sure how we would do all of that without the concept of a
storage network.

I guess time will tell on all of these fads.

> > This thread was initiated by the fact that their is an expectation,
> > that will only grow in the future, that security controls can be
> > scoped to a subdivision less than that of an entire system and in a
> > manner that doesn't cause one security policy to interfere with or
> > complicate the implementation of another.

> I dispute your "fact". I understand that some people believe that,
> but I also know that they haven't been told to expect that, at least
> not by the developers who are in a position to make it happen.

All I can speak for are the groups that we are engaged with who
indicate that they believe that workload specific security controls
are a reasonable, if not necessary requirement, for how software
development is evolving, and who have an interest in seeing what TSEM
represents available on Linux.

Our conversations in this forum would suggest you believe such ideas
are completely misguided.  From your perspective and experiences, that
may not be an unreasonable on systems that are supporting adversarial
parties.

This is security, so no one wants to talk about who may be doing
something and how.  FWIW, the people who contemplate this as a useful
advancement represent a formidable body of experience in the security
industry.

> > If current industry experience is any example, the one causing the
> > most problems will get turned off.  Or administrators will be left
> > trying to reason as to what security controls are actually being
> > achieved, which is always hazardous.

> <snark - sorry>
> Horror of horrors! Users have no business understanding the security
> policy their system implements! You may as well let them write their
> own programs!
> </snark - sorry>

I did 107 miles of cycling yesterday, in the glacial moraine lake
country of West-Central Minnesota, trying to parse what the above
means.

The best that I can come up with is that only systems administrators,
or perhaps security personnel, should understand what security
controls are implemented and how.

All the environments we have experience with suggest that everyone is
on the same team; platform engineers, administrators, developers,
security personnel, quality assurance et.al.  They are all focused on
having a solution be as secure as possible.

Some have watched these conversations and don't understand why it
would be unreasonable for a development team to be able to implement
controls that could catch a possible defect in their application
stack, before system wide controls would need to stop the behavior.

> > With respect to our work, if you believe that we are looking at a
> > namespace as an isolation concept you have misunderstand our
> > motivations, objectives and implementation.
> >
> > The LSM infrastructure represents the basis set of information that
> > can be used to model the security behavior of a platform.  If it does
> > not, it cannot adequately enforce effective security controls, since
> > by definition, it would have insufficient visibility into all security
> > relevant behavior.

> You have it backwards. The LSM infrastructure is driven by the needs
> of the security modules. If no one needed a hook for bind() we
> wouldn't have one.

You misinterpret my point, let me see if I can clarify.

The LSM, over the course of its development, has developed a
significant body of security inspection points, at the expense of a
fair amount of pain as Paul Moore would seem to suggest, for what has
been determined to be security significant actions, all to support the
needs of various security enforcement systems.

It may not represent all relevant security behavior, but it is the sum
of what is available for Linux as a platform, you cannot get any
better visibility, without adding more hooks, which seems to be
increasingly problematic and conflict laden.

So TSEM comes at this from the perspective of: "If life gives you
lemons, make lemonade".

We take all of the available information that these interception
points can generate and use it to enable the application of
mathematical models that range through the spectrum of deterministic,
quasi-deterministic, and with an increasing relevance, machine
learning models.

All of this provides a pathway to security model resolution that
represents a detection and interdiction strength that equals the sum
of what all the other LSM security schemes can produce, put together.

If additional hooks get added and they make sense from a modeling
perspective, any security models implemented via TSEM will
gain additional resolution.

> > There are at least three ways this information can be used:
> >
> > The LSM can be used to enforce a system wide security policy through
> > mandatory access controls, your area of interest and endeavor.

> MAC has been an area of interest of mine for a long time, but is
> hardly the only one. Unfortunately, the other things I want to do
> require stackability. They don't require either/or with SELinux (or
> AppArmor, or Smack) but they do use cred blobs.

Presumably a security token bearing scheme, we will look forward to
seeing it.

> > An equally valid concept is for developers to use this information
> > to verify that the security behavior of workloads that they develop
> > are consistent with what they desire.

> Err, no. That assumes that the information is sufficiently complete
> to identify any possible interesting behavior. There's no way I
> would claim the LSM infrastructure provides that.

Again, with reference to the discussion above, it is the best that
Linux can do as a platform.  If TSEM's security model cannot detect an
aberration, by definition, there would be no reason to expect that any
of the other LSM based security controls could detect and act on the
threat.

A final point.

TSEM models are exquisitely sensitive to deviations in the security
behavior of a workload.  You would presumably have little interest in
taking the time to actually test TSEM with the Quixote utilities but
doing so may be illuminating for you or others within the Linux
security community.

The contributing factor to this high sensitivity is the security state
coefficient generation function that is used.  The 'Event Modeling'
section of the TSEM document, starting at line 704, goes into some
detail on this aspect of the security model.

From a big picture perspective, every corpus of executable code will
have its own representation of any of the security behaviors that the
LSM is capable of tracking.  The TSEM documentation has practical
examples of how this manifests itself in practice.

> > A third possible use case of the LSM, since it represents access to
> > all of the information that describes the security state of a
> > platform, is to drive machine learning based analysis and
> > interpretation of the security status of a system.

> Nope. The claim that LSM provides access to "all of the information"
> is fallacious. It provides access to the information that existing
> security modules have asked for, and no more.

Hopefully we we have taken that issue to task.

> > The latter two use cases benefit from the ability to reduce the scope
> > and complexity of the model being analyzed, which is the intent of the
> > TSEM security modeling namespaces.
> >
> > I'm just hazarding a guess here, no judgement implied, but I would
> > assume you view phenomenological modeling, machine learning and
> > artificial intelligence as irrelevant endeavors with respect to
> > security?

> Oh no, They are likely to be very relevant. Alas, I don't expect the
> general populous to listen to Artificial intelligence any better
> than they listen to Natural intelligence. I fully expect AI to
> provide significant insights, but the audience will be the security
> community, not the user community.

Once gain, nothing about TSEM involves the user community, unless of
course, the user community means the development teams that are
putting the application stacks on the platform.

TSEM is designed to provide a mechanism for machine learning to have
access to what by definition, is all of the relevant security behavior
information that Linux has available to it as a platform.  The primary
user community will be data science teams.

> > We have direct and constant dialogue with a group that has around 6000
> > virtual machines running 30,000+ containers at any given instant in
> > time.  Every VM is running, I believe, three CrowdStrike kernel
> > modules and other supportive infrastructure that are feeding 'machine
> > learning' telemetry into the cloud for security analysis.  I also
> > believe there are Kubernetes sidecars analysing container behavior in
> > the mix as well.

> What is the AI looking for? How do you know if it is "security"
> you're analyzing, as opposed to teen-age buying patterns?

I wouldn't have a clue as to what they are looking for, you would need
to ask the CrowdStrike security engineering teams.

Given how closely guarded security technology is, with machine
learning models considered the most closely guarded secrets there are,
it seems unlikely they would tell you.

Their current 35.11 billion dollar valuation is dependent on their
ability to detect anomalous platform security behavior, however they
do it, if you believe their web-site, it is through event modeling and
artifical intelligence schemes implemented in the 'cloud'.  I suspect
you would need to run a request up through your chain of command to
Pat Gelsinger to try and get access to exactly what they are doing.

Pat Gelsinger taking George Kurtz to lunch, or some similar momentous
exchange, is where those types of deals for exchange of cooperation
probably need to get done.

You had suggested in a previous e-mail that there are software
'snake-oil' salesman out there, maybe that is what CrowdStrike
represents, if so they are making a ton of money doing it.

> > None of which is optional, given that the conversations surrounding
> > the technology consists of; "Run this because our insurance says we
> > have to".
> >
> > The beauty in Linux is that you can ignore all of this and run
> > SeLinux, but to say that resoure namespaces, compartmentalization and
> > modeling are irrelevant, flies in the face of how security is being
> > done.

> I often see cases where someone tries to implement a secure behavior
> using sophisticated mechanisms when a simple mechanism intended to
> address that specific issue is already in the system. That point
> that lots of people are using these mechanisms is valid, but in way
> too many cases far from the easiest or most reliable way to go about
> solving the problem.

You would probably disagree, but TSEM is about an easier way of doing
things.

> >>> The 10 years of experience we have had with building systems, and
> >>> feedback we have received from collaborators with significant
> >>> experience in critical infrastructure, drove the focus in TSEM on
> >>> strictly partitioned and workload based security controls.
> >> The 45 years of experience we have had with building systems at
> >> every level from network appliances, through user interface engines
> >> and multi-level secure supercomputers convince us that workload
> >> based controls can never provide anything beyond grandiose security
> >> theater.
> >>
> >> We have often claimed that isolation (partitioning, if you prefer)
> >> is easy, sharing is hard. Building a system security policy based on
> >> alleged "safe" existing behavior is at best naive.

> > Personally, I've actually got two years on that, started with writing
> > assembler code to modify the functionality of RDOS running on Data
> > General Nova 2's, circa 1976.  Edited microcode to fix the 'tired
> > microcode' problems on DG Eclipses.  Even built and ran a
> > supercomputer center for about 6-7 years.  Spent a ton of time in the
> > last few years writing micro-controller code to implement hardware
> > Trusted Modeling Agents, so I think I've been full circle as well.
> >
> > If we can put personal length issues aside, we can turn to the question
> > of security controls tuned to the needs of a workload.
> >
> > Based on your comment above, I assume your position would be that
> > 'Default deny, exception allow' security policies are inadequate or
> > unsafe?

> They are certainly prone to a particular kind of error. Program A
> accesses resource B, and the "policy" author doesn't know
> why. Rather than researching the reason that A accesses B, the
> policy is written to allow the access on the basis that A needs the
> access to do its job. Alas, giving A access to B also gives A access
> to C, which allows A to do nefarious things. Because no one ever
> contemplated the relationship between B and C, and A doesn't
> normally access C, the "policy" is flawed.

Yes, the perils of transitive security reasoning.

TSEM isn't about that, TSEM is more about the security model that
every firewall running on the planet implements.

It is all, actually, pretty straight forward.

Assume a deterministic or quasi-deterministic model (model inputs run
through a leveling algorithm).

There exists a finite field of security coefficients that will be
generated for a workload based on the security coefficient generation
algorithm in use.  By default, all coefficients in the field will deny
access to their associated event.  Unit testing of the workload
generates a sub-field of coefficients whose associated actions are
permitted.

This allows development teams to place a bounding set on the allowed
security behavior of their workload.  If you don't trust your
developers to do complete CI/CD coverage you install additional
controls as a secondary security boundary.

There are always exceptions, but our experience is that development
teams are starting to get pretty serious about the security of their
stacks and their CI/CD code coverage.

From our perspective, it doesn't seem right-headed for Linux to deny
them access to the ability to leverage mandatory control schemes to
improve their deliverable.

> ... And that's all I have time for today.

Indeed and we have probably hit the asymptotic limit of interest to
anyone who may be following along at home.

Best wishes for a pleasant summer weekend.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity

Re: [LSM Stacking] SELinux policy inside container affects aprocesson Host

[Leesoo Ahn]

2023-07-18 오전 12:51에 Casey Schaufler 이(가) 쓴 글:
> On 7/17/2023 8:24 AM, Leesoo Ahn wrote:
>  > 23. 7. 7. 23:20에 Paul Moore 이(가) 쓴 글:
>  >> On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
>  >>  > 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글:
[...]>  >> If you are interested in stacking SELinux and AppArmor, I 
believe the
>  >> only practical solution is to run SELinux on the host system (initial
>  >> namespace) and run AppArmor in the containers. Even in a world where
>  >> SELinux is fully namespaced, it would likely still be necessary to run
>  >> some type of SELinux policy on the host (initial namespace) in order
>  >> to support SELinux policies in the containers.
>  >
>  > Thank you for the reply. It really helped me to know the current
>  > status of them and what to do now.
>  >
>  > Just a little information for who is interested in the stacking that
>  > we decided to branch the LSM hooks by which lsm the current process is
>  > in instead of entirely calling them in order.
> 
> Could you describe your approach more fully?

As far as I know, the current stacking feature is implemented calling 
the entire hooks in order of 'lsm=' boot parameter. But our desire must 
be calling a proper hook at a time by a task's current LSM, for instance 
Apparmor 'or' SELinux instead of 'and'.

And so we have been considering adding two new hooks which work as the 
same as the origin hooks but additionally branch to a proper hook 
function with the information of current LSM by calling lsm_task_ilsm().

The following changes are a part of our approach,

------ code part ------
#define call_int_hook_by_ilsm(FUNC, ILSM, IRC, ...) ({                 \
        int RC = IRC;                                           \
        do {                                                    \
                struct security_hook_list *P;                   \
                int id; \
                                                                \
                id = (ILSM == LSMBLOB_INVALID) \
                        ? lsm_slotlist[0]->id \
                        : lsm_slotlist[ILSM]->id; \
                hlist_for_each_entry(P, &security_hook_heads.FUNC, list) { \
                        if (P->lsmid->slot != LSMBLOB_NOT_NEEDED && id 
!= P->lsmid->id) \
                                continue; \
                        RC = P->hook.FUNC(__VA_ARGS__);         \
                        if (RC != 0)                            \
                                break;                          \
                }                                               \
        } while (0);                                            \
        RC;                                                     \
})

[...]

int ilsm = lsm_task_ilsm(current);
ret = call_int_hook_by_ilsm(mmap_addr, ilsm, 0, addr);
------------

We are still worrying about the part of calling lsm_task_ilsm() with 
'current', it seems dangerous in some unknown cases.

What do you think about this approach, Casey?

Best regards,
Leesoo

Re: [LSM Stacking] SELinux policy inside container affects aprocesson Host

[Casey Schaufler]

On 7/23/2023 7:29 PM, Leesoo Ahn wrote:
> 2023-07-18 오전 12:51에 Casey Schaufler 이(가) 쓴 글:
>> On 7/17/2023 8:24 AM, Leesoo Ahn wrote:
>>  > 23. 7. 7. 23:20에 Paul Moore 이(가) 쓴 글:
>>  >> On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com>
>> wrote:
>>  >>  > 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글:
> [...]>  >> If you are interested in stacking SELinux and AppArmor, I
> believe the
>>  >> only practical solution is to run SELinux on the host system
>> (initial
>>  >> namespace) and run AppArmor in the containers. Even in a world where
>>  >> SELinux is fully namespaced, it would likely still be necessary
>> to run
>>  >> some type of SELinux policy on the host (initial namespace) in order
>>  >> to support SELinux policies in the containers.
>>  >
>>  > Thank you for the reply. It really helped me to know the current
>>  > status of them and what to do now.
>>  >
>>  > Just a little information for who is interested in the stacking that
>>  > we decided to branch the LSM hooks by which lsm the current
>> process is
>>  > in instead of entirely calling them in order.
>>
>> Could you describe your approach more fully?
>
> As far as I know, the current stacking feature is implemented calling
> the entire hooks in order of 'lsm=' boot parameter. But our desire
> must be calling a proper hook at a time by a task's current LSM, for
> instance Apparmor 'or' SELinux instead of 'and'.

SELinux and Smack rely on the fact that they manage security attributes
on all subjects and all objects. On a system where some objects are not
labeled because they are being managed by AppArmor instead, you are
going to have a security state that is muddled. How would you have a
host system that uses SELinux handle files in a container that is using
only AppArmor?

If the host processes never look at the files in the container you could
have a system that works the way you'd like. But how could you ensure that?


>
> And so we have been considering adding two new hooks which work as the
> same as the origin hooks but additionally branch to a proper hook
> function with the information of current LSM by calling lsm_task_ilsm().
>
> The following changes are a part of our approach,
>
> ------ code part ------
> #define call_int_hook_by_ilsm(FUNC, ILSM, IRC, ...) ({                 \
>        int RC = IRC;                                           \
>        do {                                                    \
>                struct security_hook_list *P;                   \
>                int id; \
>                                                                \
>                id = (ILSM == LSMBLOB_INVALID) \
>                        ? lsm_slotlist[0]->id \
>                        : lsm_slotlist[ILSM]->id; \
>                hlist_for_each_entry(P, &security_hook_heads.FUNC,
> list) { \
>                        if (P->lsmid->slot != LSMBLOB_NOT_NEEDED && id
> != P->lsmid->id) \
>                                continue; \
>                        RC = P->hook.FUNC(__VA_ARGS__);         \
>                        if (RC != 0)                            \
>                                break;                          \
>                }                                               \
>        } while (0);                                            \
>        RC;                                                     \
> })
>
> [...]
>
> int ilsm = lsm_task_ilsm(current);
> ret = call_int_hook_by_ilsm(mmap_addr, ilsm, 0, addr);
> ------------
>
> We are still worrying about the part of calling lsm_task_ilsm() with
> 'current', it seems dangerous in some unknown cases.
>
> What do you think about this approach, Casey?

I will put aside the question of whether having processes with
divergent security policies is reasonable for the moment. I know many
people believe that it isn't, and I think that there's real danger in
it.

I'm not a fan of making the call_ macros any fancier than they are.
I would rather see a local copy of the hook lists for processes that
use a different set than the base system.

>
> Best regards,
> Leesoo

Re: [LSM Stacking] SELinux policy inside container affects aprocessonHost

[Leesoo Ahn]

2023-07-25 오전 6:35에 Casey Schaufler 이(가) 쓴 글:
> On 7/23/2023 7:29 PM, Leesoo Ahn wrote:
>  > 2023-07-18 오전 12:51에 Casey Schaufler 이(가) 쓴 글:
>  >> On 7/17/2023 8:24 AM, Leesoo Ahn wrote:
>  >>  > 23. 7. 7. 23:20에 Paul Moore 이(가) 쓴 글:
>  >>  >> On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com>
>  >> wrote:
>  >>  >>  > 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글:
>  > [...]>  >> If you are interested in stacking SELinux and AppArmor, I
>  > believe the
>  >>  >> only practical solution is to run SELinux on the host system
>  >> (initial
>  >>  >> namespace) and run AppArmor in the containers. Even in a world where
>  >>  >> SELinux is fully namespaced, it would likely still be necessary
>  >> to run
>  >>  >> some type of SELinux policy on the host (initial namespace) in order
>  >>  >> to support SELinux policies in the containers.
>  >>  >
>  >>  > Thank you for the reply. It really helped me to know the current
>  >>  > status of them and what to do now.
>  >>  >
>  >>  > Just a little information for who is interested in the stacking that
>  >>  > we decided to branch the LSM hooks by which lsm the current
>  >> process is
>  >>  > in instead of entirely calling them in order.
>  >>
>  >> Could you describe your approach more fully?
>  >
>  > As far as I know, the current stacking feature is implemented calling
>  > the entire hooks in order of 'lsm=' boot parameter. But our desire
>  > must be calling a proper hook at a time by a task's current LSM, for
>  > instance Apparmor 'or' SELinux instead of 'and'.
> 
> SELinux and Smack rely on the fact that they manage security attributes
> on all subjects and all objects. On a system where some objects are not
> labeled because they are being managed by AppArmor instead, you are
> going to have a security state that is muddled. How would you have a
> host system that uses SELinux handle files in a container that is using
> only AppArmor?

I think we could deal with that using origin call_ macro only if the 
following cases that alloc a task, socket, make a file and so forth 
which do newing objects and subjects that must have both security 
context for preventing a security state that would be muddled. On the 
other hands, in a case of operations that like read, load, mmap are to 
call the customized call_ macro with ilsm to conditionally branch.

[...]

> I would rather see a local copy of the hook lists for processes that
> use a different set than the base system.

Could you explain the latter one, please?

best regards,
Leesoo

Re: [LSM Stacking] SELinux policy inside container affects a processon Host

[Leesoo Ahn]

I hope you have a great day today

2023-07-07 오후 11:20에 Paul Moore 이(가) 쓴 글:
> On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:

[...]

> 
> What you are looking for is a combination of LSM stacking and
> individual LSM namespacing. Sadly, I think the communications around
> LSM stacking have not been very clear on this and I worry that many
> people are going to be disappointed with LSM stacking for this very
> reason.
> 
> While stacking of LSMs is largely done at the LSM layer, namespacing
> LSMs such that they can be customized for individual containers
> requires work to be done at the per-LSM level as each LSM is
> different. AppArmor already has a namespacing concept, but SELinux
> does not. Due to differences in the approach taken by the two LSMs,
> namespacing is much more of a challenge for SELinux, largely due to
> issues around filesystem labeling. We have not given up on the idea,
> but we have yet to arrive at a viable solution for namespacing
> SELinux.
> 
> If you are interested in stacking SELinux and AppArmor, I believe the
> only practical solution is to run SELinux on the host system (initial
> namespace) and run AppArmor in the containers. 

Paul, I don't get that SELinux on the host system and run AppArmor in 
the containers is the only practical solution. Could you please explain 
that in more details?

Best regards,
Leesoo

Re: [LSM Stacking] SELinux policy inside container affects a processon Host

[Dr. Greg]

On Fri, Jul 28, 2023 at 10:54:23AM +0900, Leesoo Ahn wrote:

> I hope you have a great day today

Hi Leesoo, I hope your week is starting well.

> 2023-07-07 ?????? 11:20??? Paul Moore ???(???) ??? ???:
> >On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
> 
> [...]
> 
> >
> >What you are looking for is a combination of LSM stacking and
> >individual LSM namespacing. Sadly, I think the communications around
> >LSM stacking have not been very clear on this and I worry that many
> >people are going to be disappointed with LSM stacking for this very
> >reason.
> >
> >While stacking of LSMs is largely done at the LSM layer, namespacing
> >LSMs such that they can be customized for individual containers
> >requires work to be done at the per-LSM level as each LSM is
> >different. AppArmor already has a namespacing concept, but SELinux
> >does not. Due to differences in the approach taken by the two LSMs,
> >namespacing is much more of a challenge for SELinux, largely due to
> >issues around filesystem labeling. We have not given up on the idea,
> >but we have yet to arrive at a viable solution for namespacing
> >SELinux.
> >
> >If you are interested in stacking SELinux and AppArmor, I believe the
> >only practical solution is to run SELinux on the host system (initial
> >namespace) and run AppArmor in the containers. 

> Paul, I don't get that SELinux on the host system and run AppArmor
> in the containers is the only practical solution. Could you please
> explain that in more details?

It appears that Paul is extremely busy, so I thought the 'Quixote
Group' would try and offer some reflections that may help with your
efforts.

The most important issue in all of this is to understand that Linux
LSM's 'stack', they don't 'nest'.

If more than one LSM is enabled, their hooks will be called
consecutively until one fails or they all succeed.  There is currently
no concept of an 'LSM namespace' that would allow the actions of one
LSM to be isolated from a second LSM that is enabled.

So if you are attempting to run SELinux and AppArmor on the same host,
you need to reason through the effective security policy that results
from the combination of the SELinux and AppArmor policies.

We would certainly not profess to be the experts on LSM/SELinux that
Paul is but I believe the point he is making is that, in his opinion,
the only way to allow both policies to effectively co-habitate is to
use SELinux enforcement on the host system and AppArmor enforcement in
the container environment.

Lets see if we can reason through a hypothetical example that would
illustrate the issues involved.

If SELinux 'goes first', which will probably be the case, there will
be a need to have an SELinux policy in place that does not prohibit
the interaction of subjects and objects in the container environment,
otherwise you will get whatever the effective SELinux policy is.  Once
SELinux elects to not deny a security event, an AppArmor policy will
have the opportunity to make security decisions for the processes
running in the container environment.

As Casey has noted previously in this thread, creating this type of
environment will no doubt require some degree of sophistication and
expertise in both SELinux and AppArmor policy development and
implementation.

Hopefully the above will help facilitate further understanding with
respect to your efforts.

> Best regards,
> Leesoo

Best wishes for a productive remainder of the week and the success of
your work.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity

Re: [LSM Stacking] SELinux policy inside container affects a processon Host

[Paul Moore]

On Sun, Aug 6, 2023 at 1:16 PM Dr. Greg <greg@enjellic.com> wrote:
> On Fri, Jul 28, 2023 at 10:54:23AM +0900, Leesoo Ahn wrote:
> > 2023-07-07 ?????? 11:20??? Paul Moore ???(???) ??? ???:
> > >On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
> >
> > [...]
> >
> > >
> > >What you are looking for is a combination of LSM stacking and
> > >individual LSM namespacing. Sadly, I think the communications around
> > >LSM stacking have not been very clear on this and I worry that many
> > >people are going to be disappointed with LSM stacking for this very
> > >reason.
> > >
> > >While stacking of LSMs is largely done at the LSM layer, namespacing
> > >LSMs such that they can be customized for individual containers
> > >requires work to be done at the per-LSM level as each LSM is
> > >different. AppArmor already has a namespacing concept, but SELinux
> > >does not. Due to differences in the approach taken by the two LSMs,
> > >namespacing is much more of a challenge for SELinux, largely due to
> > >issues around filesystem labeling. We have not given up on the idea,
> > >but we have yet to arrive at a viable solution for namespacing
> > >SELinux.
> > >
> > >If you are interested in stacking SELinux and AppArmor, I believe the
> > >only practical solution is to run SELinux on the host system (initial
> > >namespace) and run AppArmor in the containers.
>
> > Paul, I don't get that SELinux on the host system and run AppArmor
> > in the containers is the only practical solution. Could you please
> > explain that in more details?
>
> It appears that Paul is extremely busy, so I thought the 'Quixote
> Group' would try and offer some reflections that may help with your
> efforts.

My apologies, yes I am rather busy at the moment, but I also stopped
following this thread a while ago as it didn't seem to be going
anywhere meaningful.  I happen to read this last email while I'm
waiting in an airport, so let me try and provide a quick explanation
about why running SELinux only in a container is a bad idea.

As you probably know, the Linux kernel has no concept of a container,
it only supports subsystem specific namespaces, e.g. mount namespace,
network namespace, etc.  SELinux does not provide a subsystem
namespace, and it does not generally concern itself with other
subsystem names.  From a SELinux perspective there is no difference
between a process running in the host namespace or a
container/namespace; both are treated the same with access control
decisions made based on the processes' SELinux domain, the type of the
target resource, and the access requested.

If one were to load a SELinux policy inside a container, even if it
were allowed, the system would likely behave in unexpected ways as the
container-loaded policy will take effect across the entire system, not
just inside the container.

-- 
paul-moore.com

Re: [LSM Stacking] SELinux policy inside container affects a processon Host

[Dr. Greg]

On Sun, Aug 06, 2023 at 03:25:32PM -0400, Paul Moore wrote:

Good morning, I hope the week has started well for everyone.

> On Sun, Aug 6, 2023 at 1:16???PM Dr. Greg <greg@enjellic.com> wrote:
> > On Fri, Jul 28, 2023 at 10:54:23AM +0900, Leesoo Ahn wrote:
> > > 2023-07-07 ?????? 11:20??? Paul Moore ???(???) ??? ???:
> > > >On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
> > >
> > > [...]
> > >
> > > >
> > > >What you are looking for is a combination of LSM stacking and
> > > >individual LSM namespacing. Sadly, I think the communications around
> > > >LSM stacking have not been very clear on this and I worry that many
> > > >people are going to be disappointed with LSM stacking for this very
> > > >reason.
> > > >
> > > >While stacking of LSMs is largely done at the LSM layer, namespacing
> > > >LSMs such that they can be customized for individual containers
> > > >requires work to be done at the per-LSM level as each LSM is
> > > >different. AppArmor already has a namespacing concept, but SELinux
> > > >does not. Due to differences in the approach taken by the two LSMs,
> > > >namespacing is much more of a challenge for SELinux, largely due to
> > > >issues around filesystem labeling. We have not given up on the idea,
> > > >but we have yet to arrive at a viable solution for namespacing
> > > >SELinux.
> > > >
> > > >If you are interested in stacking SELinux and AppArmor, I believe the
> > > >only practical solution is to run SELinux on the host system (initial
> > > >namespace) and run AppArmor in the containers.
> >
> > > Paul, I don't get that SELinux on the host system and run AppArmor
> > > in the containers is the only practical solution. Could you please
> > > explain that in more details?
> >
> > It appears that Paul is extremely busy, so I thought the 'Quixote
> > Group' would try and offer some reflections that may help with your
> > efforts.

> My apologies, yes I am rather busy at the moment, but I also stopped
> following this thread a while ago as it didn't seem to be going
> anywhere meaningful.  I happen to read this last email while I'm
> waiting in an airport, so let me try and provide a quick explanation
> about why running SELinux only in a container is a bad idea.
> 
> As you probably know, the Linux kernel has no concept of a container,
> it only supports subsystem specific namespaces, e.g. mount namespace,
> network namespace, etc.  SELinux does not provide a subsystem
> namespace, and it does not generally concern itself with other
> subsystem names.  From a SELinux perspective there is no difference
> between a process running in the host namespace or a
> container/namespace; both are treated the same with access control
> decisions made based on the processes' SELinux domain, the type of the
> target resource, and the access requested.
> 
> If one were to load a SELinux policy inside a container, even if it
> were allowed, the system would likely behave in unexpected ways as the
> container-loaded policy will take effect across the entire system, not
> just inside the container.

All reasonable and consistent, with what we had previously written
with respect to there being no notion of LSM namespacing.

To further assist Leesoo and others who may be following this, you had
suggested the following earlier in this thread:

Paul> If you are interested in stacking SELinux and AppArmor, I
Paul> believe the only practical solution is to run SELinux on the
Paul> host system (initial namespace) and run AppArmor in the
Paul> containers.

Which would seem to apply that in a 'stacked' LSM configuration of
SELinux and AppArmor, there would be a possibility of using the two
LSM's without them 'colliding', the equivalent of what could be
considered a 'nested' LSM implementation.

Casey had also suggested in this thread that this would be possible at
the risk of a system that would be difficult to reason about.

Were our previous comments correct, that the path forward would be to
have SELinux configured in a manner where it would not act on any of
the subject/object interactions that occur in the container
environment that is using AppArmor?

If so, would the path forward be to implement an SELinux policy that
would place the process initiating the namespace, and its descendants,
in an unconfined domain with respect to the assets in the scope of the
container?

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity

Re: [LSM Stacking] SELinux policy inside container affects a processon Host

[Paul Moore]

On Tue, Aug 8, 2023 at 2:41 AM Dr. Greg <greg@enjellic.com> wrote:
> On Sun, Aug 06, 2023 at 03:25:32PM -0400, Paul Moore wrote:
> > On Sun, Aug 6, 2023 at 1:16???PM Dr. Greg <greg@enjellic.com> wrote:
> > > On Fri, Jul 28, 2023 at 10:54:23AM +0900, Leesoo Ahn wrote:
> > > > 2023-07-07 ?????? 11:20??? Paul Moore ???(???) ??? ???:
> > > > >On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote:
> > > >
> > > > [...]
> > > >
> > > > >
> > > > >What you are looking for is a combination of LSM stacking and
> > > > >individual LSM namespacing. Sadly, I think the communications around
> > > > >LSM stacking have not been very clear on this and I worry that many
> > > > >people are going to be disappointed with LSM stacking for this very
> > > > >reason.
> > > > >
> > > > >While stacking of LSMs is largely done at the LSM layer, namespacing
> > > > >LSMs such that they can be customized for individual containers
> > > > >requires work to be done at the per-LSM level as each LSM is
> > > > >different. AppArmor already has a namespacing concept, but SELinux
> > > > >does not. Due to differences in the approach taken by the two LSMs,
> > > > >namespacing is much more of a challenge for SELinux, largely due to
> > > > >issues around filesystem labeling. We have not given up on the idea,
> > > > >but we have yet to arrive at a viable solution for namespacing
> > > > >SELinux.
> > > > >
> > > > >If you are interested in stacking SELinux and AppArmor, I believe the
> > > > >only practical solution is to run SELinux on the host system (initial
> > > > >namespace) and run AppArmor in the containers.
> > >
> > > > Paul, I don't get that SELinux on the host system and run AppArmor
> > > > in the containers is the only practical solution. Could you please
> > > > explain that in more details?
> > >
> > > It appears that Paul is extremely busy, so I thought the 'Quixote
> > > Group' would try and offer some reflections that may help with your
> > > efforts.
>
> > My apologies, yes I am rather busy at the moment, but I also stopped
> > following this thread a while ago as it didn't seem to be going
> > anywhere meaningful.  I happen to read this last email while I'm
> > waiting in an airport, so let me try and provide a quick explanation
> > about why running SELinux only in a container is a bad idea.
> >
> > As you probably know, the Linux kernel has no concept of a container,
> > it only supports subsystem specific namespaces, e.g. mount namespace,
> > network namespace, etc.  SELinux does not provide a subsystem
> > namespace, and it does not generally concern itself with other
> > subsystem names.  From a SELinux perspective there is no difference
> > between a process running in the host namespace or a
> > container/namespace; both are treated the same with access control
> > decisions made based on the processes' SELinux domain, the type of the
> > target resource, and the access requested.
> >
> > If one were to load a SELinux policy inside a container, even if it
> > were allowed, the system would likely behave in unexpected ways as the
> > container-loaded policy will take effect across the entire system, not
> > just inside the container.
>
> All reasonable and consistent, with what we had previously written
> with respect to there being no notion of LSM namespacing.
>
> To further assist Leesoo and others who may be following this, you had
> suggested the following earlier in this thread:
>
> Paul> If you are interested in stacking SELinux and AppArmor, I
> Paul> believe the only practical solution is to run SELinux on the
> Paul> host system (initial namespace) and run AppArmor in the
> Paul> containers.
>
> Which would seem to apply that in a 'stacked' LSM configuration of
> SELinux and AppArmor, there would be a possibility of using the two
> LSM's without them 'colliding', the equivalent of what could be
> considered a 'nested' LSM implementation.

SELinux applies access control across the entire system, regardless of
what namespaces may be configured on the system.  Loading a SELinux
policy in the host/initial-namespace during early boot helps ensure
proper labeling of system entities and a better user experience;
loading a SELinux policy in a container/namespace can lead to
surprising and unpredictable results across the whole of the system.
AppArmor is different in that it has support for
containers/namespaces.  Running SELinux on the host and AppArmor in a
container isn't so much about preventing collisions, they are still
simultaneously running and applying their security policies, it is
more about ensuring the LSMs, the admins, and the users all see
compatible views of the system.

Please do not confuse any of the above as a 'nested' or namespaced LSM
layer; the current in-progress LSM stacking is simply that: the
ability to stack some combination of LSMs in a few prescribed
configurations.  Talking about 'nesting' or 'namespacing' at the LSM
layer is confusing at best, and misleading at the worst.

-- 
paul-moore.com