> 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).
Because it is more popular.
> 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.
No, it doesn't require grasping a complex conceptual model. At all. All it
really requires is audit2allow and some documentation reading. You barely
have to understand anything. This is ridiculous.
> 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.
Look at the refpolicy mailing list instead.
> 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.
Current Debian policy is the sensible policy. Don't ship either by default.
AppArmor is snake oil. SELinux is hard to do right, and it will never work where everything works perfectly and completely secure by default, but it gets you closer.
It's almost like this security thing is hard to get right.