Still waiting for stackable security modules

Posted Nov 1, 2022 23:14 UTC (Tue) by jhoblitt (subscriber, #77733)
In reply to: Still waiting for stackable security modules by cschaufler
Parent article: Still waiting for stackable security modules

It also allows different frameworks to be used for different applications. Today, if you have an app that comes with selinux profiles and another with apparmor, you have a only use one LSM framework. This is starting to be a major "bummer" in the containerization world.

Still waiting for stackable security modules

Posted Nov 3, 2022 3:59 UTC (Thu) by jamesmorris (subscriber, #82698) [Link] (3 responses)

So this means you need to support both AppArmor and SELinux at the same time in some meaningful way for the entire system. What does that policy look like and who is going to be able to support it?

Still waiting for stackable security modules

Posted Nov 3, 2022 15:59 UTC (Thu) by cschaufler (subscriber, #126555) [Link]

Yes, it does. https://static.sched.com/hosted_files/lsseu2022/8c/2022-L...
Look at how much the SELinux reference policy has "evolved" over the past 20 years before demanding that the AppArmor and Smack policies be "complete" on day one.

Still waiting for stackable security modules

Posted Nov 3, 2022 16:31 UTC (Thu) by jhoblitt (subscriber, #77733) [Link]

Yes, exactly, the major concern is maintenance of the security policy. With my operator hat on, the ideal situation is that the policy configuration is provided by the upstream project. This means the policy only needs to be audited rather than written from scratch to work with the one LSM which is active on the system.

A secondary concern is that the current situation requires a flag day change between LSMs, which is a high burden.

Still waiting for stackable security modules

Posted Nov 4, 2022 13:39 UTC (Fri) by jrjohansen (subscriber, #75010) [Link]

Yes to a point, how much will depend on what you are trying to enable/support. f you are using AppArmor for application sandboxing instead of host level security it can make sense.

For the case of a system LXD style container running Ubuntu on an SELinux host minimal support needed. AppArmor needs to be enabled in the kernel, the LSM stack needs to be setup and the container manager needs access to the AppArmor interfaces (this may require some policy changes). The container manager sets up an apparmor policy namespace and the container loads its policy into that namespace and it only affects that container.

Application containers like Snap is doing can be made to work with minimal support like system style containers, but do need a little integration on the system for full confinement. In this use case AppArmor is only working to enforce container restrictions on the application, leaving host security to another LSM like SELinux.

Setting up AppArmor with a full system host policy + SELinux I don't see as being useful.