Re: Let's enable AppArmor by default (why not?)

[Neal Gompa]

x 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)

Re: Let's enable AppArmor by default (why not?)

[Neal Gompa]

On Thu, Oct 26, 2017 at 1:49 PM, intrigeri  wrote:
> 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!
>

I'm not sure that's actually the case. I can't really speak for it, as
I generally don't use Debian (I primarily use Fedora, openSUSE,
Mageia, and CentOS). One thing I have observed is that there are no
guidelines or policy documentation from Debian on how to install
policy modules. That's a very annoying gap for anyone who wants to
leverage the modular nature of SELinux policies.

Many, many, many common services and applications ship SELinux policy
modules, and they are not packaged in Debian because no one is sure
how to do it.

I've more or less fallen back to telling people to use the Makefile to
build and install the module and hope that Debian does The Right
Thing(TM). But of course, I don't know if this is true.

>>> * 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 d