SELinux is unmanageable; just turn it off if it gets in your way

>It doesn't matter if your OS or containers are made of security swiss cheese as long as compromising one thing doesn't lead to compromising another.

I hope you never work with customer related data.

Hum, as another admin... No thanks.

With IllumOS I can agree on zones, I can partially agree on lpar on AiX, I can accept GNU/Linux limits with cgroups. Enlarging the attack surface to follow the current wannabe Gurgle mania... No. Like no in the recent past to full-stack virtualization on x86 to enrich VMWare, buy big desktops sold as powerful servers just to play matryoshka doll for someone else business...

Of course, it's hard to satisfy hw "subdivision" vs sw subdivision, in the past we have tried the hw path with blades for the small side, infiniband and co for the large side and both proved to be not very scalable but the issue is in actual OS design and can only be solved changed that: An OS mush be a single application, with internal namespacing, networking. We have seen it in various past OSes. It's about time to make them again accepting that the IBM model is good only for IBM, witch means for selling stuff to people having no choice but buy or ignoring something better can be done.

I think my main problems with AppArmor are the feature set isn't coherent across all distros that use it and it isn't integrated too well with audit tools. OpenSUSE ships distro patches that are a major hack to make ausearch properly show AA denials, while others need to look at dmesg and remember to disable printk ratelimit. The supported feature set is fun, the kernel mainline vs Ubuntu vs SUSE feature sets differ a lot. Ubuntu supports fine grained socket mediation (as in specific ops) & dbus. OpenSUSE supports some of the socket mediation, but as life has demonstrated some rules that work on Ubuntu are incorrectly downgraded and for instance all unix socket access gets blocked (though thanks to the AppArmor folks this got fixed now). Arch which I'm considering to be close to mainline has no dbus and no fine socket mediation. In theory one can use the same policy file on all systems, but the way it gets downgraded is not always predictable. At least the features are somewhat discoverable though /sys/kernel/security/apparmor tree, but I don't know what happens when say the kernel reports dbus mediation, but dbus-daemon was built without it. Then there are also some missing features, I think the abstract socket mediation is still not there. Lastly, the parser is super slow and memory hungry, especially when throwing some AARE heavy profiles at it. It happens that Ubuntu Core makes heavy use of apparmor profiles to lock down snaps on embedded Linux devices, and all the timings data that we collect show calling out to apparmor parser taking the largest chunk of the snap installation time.

FWIW mediation of dbus & network is already supported by SELinux in all implementations I've tried, but then SELinux has a separate set of warts. Eg. trying to use the same source policy and building it on hosts with different tooling/refpolicy. Using `optional_policy` doesn't cut it if types are not known at all, and as debugged with good folks from #selinux, the only way to work around this was using `ifndef` and passing defines to m4 interpreter.

Exactly this. I’ve run SELinux on for various workloads for over a decade and have barely ever had to touch audit2allow. And what I have done is codified in ansible so you can just copy and adjust for new cases.

Eh, I generally disagree - but not completely.

Set SELinux to permissive for your personal systems at your own relative risk.

Never disable it, you'll end up in a situation where nothing is labeled and relevant policy adjustments probably don't exist. Making re-enabling it later a nightmare.

I'd argue it's particularly advantageous for desktops where untrusted software is a more common occurrence... and other controls (eg: network isolation) aren't as robust.

For business use, it's probably worth some investment. Any serious compliance program will probably want an explanation for why you aren't using it/equivalent.

It's not some amorphous thing, it can be learned and handled. I used to routinely disable it but I haven't in years

There are clearly defined objects and areas of responsibility. It's just buried under piles of documentation

semanage and all of the other tools are indeed cryptic, but you can generally get by with two steps:

- Identifying triggered hits

- restore contexts / update the policy as appropriate for this use case

I won't say it's easy, an employer of mine paid for two weeks of training that focused a lot specifically on this.

A lot of it I can't even articulate that well, I've just developed a set of patterns

Edit; obligatory mention: https://stopdisablingselinux.com/