Hi Neal & others, Neal Gompa: > I was recently pointed to the thread going on debian-devel about > enabling AppArmor LSM in Debian, and as I read through your proposal, > I felt it should be warranted to point out a few things in regards to > the SELinux comparison:
Thanks a lot for your carefully worded and extremely well sourced email! I've already learned quite a few interesting things. > intrigeri wrote: >> Why AppArmor and not SELinux? >> ----------------------------- >> >> SELinux is another LSM that tackles similar problems. [...] >> * Enabled by default in RHEL so in theory a great number of sysadmins >> are at ease with it (see below why reality may not match this). > It's also important to note that it is also enabled by default in > Fedora, which is the upstream for RHEL. Sure. I didn't mention it because I don't see this as very relevant in the context of this discussion: it's a fact that many sysadmins active in Debian have to use RHEL/CentOS at work, but I doubt many Debian people are this much exposed to Fedora, so I don't think it's a good source of pre-existing SELinux expertise in Debian. > I do know of users of SELinux in Debian and Ubuntu, though they often > fork from refpolicy or fedora-selinux the bits they want to use and > install it on top of the current refpolicy offered in Debian. Interesting. It's good to know there are such options to use SELinux on Debian :) It also says something that I'm inclined to interpret as "the SELinux policy in Debian is not ready for prime-time". I'd be glad to be wrong though! >> * Writing, maintaining, auditing and debugging SELinux policy >> requires grasping a complex conceptual model; I am told this is not >> as easy as doing the same with AppArmor. > This is not really true. While it is true that the conceptual model is > more complex, the tooling for doing all the regular work with SELinux > is great. In many cases, the tools can analyze what's happened and > suggest a course of action about how to fix it. If it looks like a > bug, they suggest filing one with the vendor (in my case, when weird > things happen with the SELinux policy in Fedora, bugs get filed on > selinux-policy with the information from setroubleshoot so that things > can get fixed). This sounds great UX; it makes me wish to try it out and draw inspiration from it to improve AppArmor's UX too. Thanks for sharing. > As for the complexity of making policies and policy modules, I've > written a few policy modules, and they're not that bad. You can make > some pretty simple policies if you don't want to expose any > administrative tunables. That said, even with the tunables, it's not > that bad. > For example, the container-selinux policy module is pretty easy to > understand: https://github.com/projectatomic/container-selinux > The refpolicy documentation is pretty comprehensive too: > http://oss.tresys.com/docs/refpolicy/api/ I had a quick look and I agree: it's not that bad. Still feels much scarier than AppArmor policy to me, but I'm clearly not the right person to judge these days :) >> * As far as I could understand when chatting with sysadmins of Red >> Hat systems, this has resulted in a culture where many users got >> used to disable SELinux entirely on their systems, instead of >> trying to fix the buggy policy. > Back in the RHEL 5 days, this is definitely true. And if many of of > the Red Hat sysadmins you've talked to primarily maintain RHEL 5 > systems (which is not unlikely), then it makes sense. Back in the RHEL > 5 days (circa 2007), the tooling was very primitive, and for the most > part, the troubleshooting tools didn't exist. > Today in Fedora and RHEL 7, the tooling is very advanced, and in > almost every case where I've hit AVC denials in SELinux, > setroubleshoot has given me very useful information including > suggested course of actions to actually fix it locally. OK, this does explain things. It's sad that this culture has been created in the first place — changing users' habits is hard: the sysadmins I'm talking about kept "disable SELinux" in their post-installation checklist and have no clue that RHEL 7 solved all these problems. I suspect they'll need many more years to realize they could change their habits. I'll tell them about it! Now, my point is not very relevant in the context of the Debian discussion: hopefully not many Debian users are affected by this "always disable SELinux" culture. >> I've seen the opposite happen with >> AppArmor, which is good: for example, pretty often bug reporters to >> the Debian BTS document themselves how they could workaround the >> problem locally *without* turning AppArmor off. Looking at open >> bugs in the BTS against src:refpolicy, this seems to happen very >> rarely for SELinux, so I wonder if it would be realistic to ship >> Debian with SELinux enforced by default and have our community >> support it. I think this was not contested. >> * https://wiki.debian.org/SELinux/Issues says "Graphical/Desktop >> installs of Debian are not heavily tested with selinux, so you >> might run into quite some issues". > This is true for both AppArmor and SELinux. With the exception of the > Snap case, neither MAC has been optimized for handling desktop issues > that much. Right, they were not optimized for such use cases. But something very close to Graphical/Desktop installs of Debian *are* heavily tested with AppArmor thanks to Debian derivatives (Ubuntu, Tails) that enable AppArmor. So I can't really agree with "This is true for both AppArmor and SELinux". >> * I'm not aware of any Debian derivative shipping with SELinux >> enabled by default. If that's correct, then it means that we would >> have to deal with quite some policy compatibility issues ourselves. > To be fair, refpolicy was RC'd from Debian in 8, due to failing to > build and no one fixed it quickly enough. It was reintroduced in > Debian 9, though. I have not personally tested the SELinux support in > Debian 9, but I've heard from a few friends that it does work. Good to know :) >> To me, the complexity of SELinux is a deal breaker: it seems that we >> would need to get lots more expertise and energy to enforce SELinux by >> default than doing the same with AppArmor. > The unfortunate thing is that more comprehensive security models do > lead to more complexity. ACK. If we had a strong team of people dedicated to supporting SELinux in Debian, e.g. as part of their paid job, it may be an option; my understanding is that it's basically how distros that ship with SELinux can handle it. But we have no such thing in Debian, and AppArmor seems more suited to the more distributed model Debian is based on: many developers will need to learn _a little bit_ about AppArmor, and with the existing expertise we have in the project that can provide advice & help when needed, we should be good without having to hire ninjas (and FWIW Ubuntu handles it similarly). > But I definitely don't want people to think that SELinux is some crazy > mountainous path full of terrible unknowns. Thanks a lot for clarifying! Best regards, -- intrigeri
