Still waiting for stackable security modules

Posted Nov 1, 2022 18:41 UTC (Tue) by jamesmorris (subscriber, #82698)
Parent article: Still waiting for stackable security modules

Some questions often missing from these discussions:

- What are the use-cases for arbitrary stacking of AppArmor with SELinux or Smack (for example) ?
- Do any such use-cases justify a large, invasive change to a core kernel security framework?
- Will this improve Linux security, and Linux security usability?
- Which distro or other major user will to commit to ship with all of this enabled in production, so that the code gets exercised at scale?
- Will they commit to fixing any bugs found and help with long term upstream maintenance?
- Is there consensus in the Linux kernel security community on any of these issues, and also the on the technical merit of all of the patches submitted?
- Has all the code been reviewed by maintainers and experts in all of the subsystems impacted?

Still waiting for stackable security modules

Posted Nov 1, 2022 22:38 UTC (Tue) by cschaufler (subscriber, #126555) [Link] (6 responses)

AppArmor+Smack gives you the best of both path based ease-of-use and complete system MAC, without the overwhelming complexity of an SELinux policy. If you like the complexity of SELinux policy, use that instead of Smack. The "invasive" changes to the core framework are nothing more than parameter type changes. Allowing multiple security modules to have cred based attributes reduces the restrictions on what modules can work together. The single "major" module restriction prevents adding many useful additions. Ubuntu. They are already doing so. It's years since there has been an objection to stacking presented. I think that Yama put the "only one LSM at a time makes sense" argument down. It's not through lack of proposal, submission, notification and, in some cases, hounding.

Still waiting for stackable security modules

Posted Nov 1, 2022 23:12 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> If you like the complexity of SELinux policy, use that instead of Smack.

I tried to use Smack a couple of times and I failed to find anything that is simplified compared to SELinux.

And both of them need the brain-dead "labeling".

Still waiting for stackable security modules

Posted Nov 1, 2022 23:14 UTC (Tue) by jhoblitt (subscriber, #77733) [Link] (4 responses)

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.