On Tue, Aug 8, 2023 at 2:41 AM Dr. Greg [off-list ref] wrote:

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

quoted

On Sun, Aug 6, 2023 at 1:16???PM Dr. Greg [off-list ref] wrote:

quoted

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

quoted

2023-07-07 ?????? 11:20??? Paul Moore ???(???) ??? ???:

quoted

On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn [off-list ref] wrote:

[...]

quoted

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.

quoted

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.

quoted

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