Hello, 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:
> Why AppArmor and not SELinux? > ----------------------------- > > SELinux is another LSM that tackles similar problems. > > Disclaimer: I've picked AppArmor years ago and didn't look much at > SELinux recently, so some of what follows may be totally wrong or > outdated. Sorry! Debian SELinux people, if you don't mind please help > me get the basic facts right :) > > Pros: > > * Allows mediating more kernel objects / interfaces than AppArmor, so > policy can be made stricter and safer given sufficient expertise > and available time for maintenance. > > * 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. > * A quick look at popcon suggests that SELinux might be more popular > in Debian than AppArmor, but I'm not sure I am interpreting the > numbers right (and I suspect that just like AppArmor, the popcon > won't tell us if users who have installed the relevant support > packages actually run their system with the corresponding LSM > enabled & enforced). > 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. > Cons: > > * 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). 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/ One of the members of the Red Hat/Fedora SELinux team maintains a nice blog describing improvements as they come: https://lvrabec-selinux.rhcloud.com/ There's a few videos done by Red Hat folks on SELinux that are worth watching on YouTube: * Are you listening to what SELinux is telling you?: https://www.youtube.com/watch?v=Wv9kwlabdlo * Security-enhanced Linux for mere mortals - 2015 Red Hat Summit: https://www.youtube.com/watch?v=cNoVgDqqJmM * SELinux by Paul Moore: https://www.youtube.com/watch?v=j_do1yfPISw There's also a great video by Noah Chelliah about SELinux: * Security Enhanced Linux | Ask Noah 9: http://www.jupiterbroadcasting.com/115151/security-enhanced-linux-ask-noah-9/ > * 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. 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. > 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. It would probably not be all that difficult to also support the case of submitting bugreports to the BTS (it currently can for Bugzilla based systems, such as Red Hat Bugzilla and SUSE Bugzilla). Most of my fellow RHEL/CentOS users on RHEL/CentOS 7 have been pretty happy with leaving it on in enforcing mode with the default targeted policy. It's well-tuned and stays out of the user's way in most cases. I won't say it's perfect, and there certainly have been issues. But when they do happen, they do get filed in the Red Hat Bugzilla for the SELinux team to know about it and fix. You can see some of the bug reports that roll in the Red Hat Bugzilla here: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_QA&bug_status=VERIFIED&bug_status=CLOSED&classification=Fedora&component=selinux-policy&list_id=7918855&product=Fedora&query_format=advanced > * 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. There *is* some work in Fedora for confining browsers, in part due to the usage of plugins, but modern browsers ship their own seccomp-based confinement mechanisms, so SELinux is usually configured to stay out of the way and just make sure the process doesn't access anything a browser isn't supposed to access. And I'm hopeful that eventually even the Snap case, SELinux-based confinement will come soon. I've already written a basic SELinux policy for snapd itself (no such profile exists for AppArmor, IIRC), and I hope to continue to extend and improve the state of the SELinux policy for snapd so that we know what it does and the daemon itself doesn't do things it's not supposed to. > * 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. > 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. > Now, if for some reason the project prefers to ship with SELinux > enforced instead of AppArmor, fine by me: I would strongly prefer this > option to nothing at all. I personally would like to see Debian ship SELinux by default, but as I'm not a part of Debian, my opinion doesn't matter. ;) But I definitely don't want people to think that SELinux is some crazy mountainous path full of terrible unknowns. If you have any other questions or would like to know more, feel free to ask, and I'll do my best to answer. :) Best regards, -- Neal Gompa (FAS: ngompa)