[frabbit]

Important note on this:

"Fortunately, the default security hardenings in most container environments are enough to prevent container escape. Containers running with AppArmor or SELinux are protected. "

So, all that hard work on SELinux continues to pay off.

[concerned_user]

Sadly, many answers to questions related to selinux issues, or howto's start with: Disable selinux.

[chunkyks]

Things may have changed, but the last few times I looked, it was breathtakingly hard to a) identify if /when selinux is what's screwing you, then b) get selinux to stop it.

I really wanted an audit mode that could also say "this command will unlock the specific thing I just blocked".

That was a few years ago. Since then, I've turned off selinux whenever I'm getting screwed by some opaque process, stuff starts working, and closing it back down while leaving what I need open remains impossible black magic.

[chucky_z]

Is audit2allow the thing you want?

[loudmax]

Probably yes, but audit2allow is very hard to reason about. You can run it and hopefully it will enable you to allow the things you want to allow without also allowing things you didn't want.

Red Hat doesn't seem to have any interest in making SELinux more accessible than programming in assembly. The UX for the tooling around SELinux is an absolute dumpster fire.

[mhitza]

On server environment that command is most of the time not installed by default.

Quick! tell me which package I need to install to get audit2allow on a system; without using Google, dnf whatprovides, or repoquery --whatprovides.

I'm still baffled why such an essential tool for quickly assessing violations and potential selinux booleans quick fixes is part of a obsfucated package name. I think some setroubleshoot family of tools might be installed by default on some systems, even if most answers will guide people to just use audit2allow.

[chunkyks]

I recall taking a stab at audit2allow a few years ago, and finding that it was incredibly opaque and felt like practising dark arts.

At this point, it's probably true that I should get onboard the SELinux train and learn it properly, but it's just... ain't nobody got time for that.

[chucky_z]

I believe this is considered one of the best videos: https://www.youtube.com/watch?v=_WOKRaM-HI4

[AaronFriel]

I strongly believe that software that works for users is better than software that doesn't, and it's clear that for most lay folks, SELinux is software that doesn't work.

SELinux remains inscrutable and unusuable to the lay person. Microsoft had the same problem with Windows XP and especially after its service pack 2 when the Windows Firewall was introduced, that it was difficult to debug and applications didn't prompt to open ports or have an API to do so. So many a lay person posted on forums "disable firewall".

Users don't care why their tools don't work, they don't understand why or how to fix it. Technically complex SELinux audit tutorials are not helpful. There needs to be real, genuine attention to user experience an almost tutorial like CLI command. Something so simple anyone could safely make a program run. Whether that program is safe itself is another question, and users should be told that too.

[frabbit]

> it's clear that for most lay folks, SELinux is software that doesn't work.

I have always used selinux enabled systems. For the first few years it was a bit confusing and frustrating at times, but for the last (decade?) I have never had to butt heads with it. The default policies shipped by e.g. Fedora (a userland closest to the development of this work and therefore probably better maintained than some others) work out of the box without hassle.

This very article refutes your assertion: here we see SELinux working for ordinary users without any additional fiddling. You, on the other hand, are probably exposed to this privilege escalation.

[AaronFriel]

That's not my assertion, my assertion is that SELinux doesn't work for a lot of people even if it works for you or I; and that's why you see the advice to disable it in forum posts.

To be clear: SELinux is an important mitigation - just like the Windows Firewall - and one should not disable either.

[frabbit]

I disagree. The advice to disable SELinux, like your assertion that it's too complicated for ordinary users, belongs to an older time. It's time to lay that myth to bed.

Sure, if you're messing around with k8s and doing fun eBPF stuff you are going to need to be careful. But for just installing an OS, running it to do some web-browsing, gaming, image editing, wordprocessing? I would be highly surprised if the defaults do not work.

[AaronFriel]

> The advice to disable SELinux... time to lay that myth to bed.

I think we agree, and Fedora / Red Hat have done great work setting up great defaults.

But when a user encounters an issue with SELinux, the lack of feedback mechanisms to help them onto a better path results in them finding that advice.

[pjmlp]

One of the best things on Android is having SELinux and seccomp enabled.

[silisili]

I'd argue the vast majority of Linux desktop users (already a small group) don't use SELinux. So naturally when trying to help someone using something we don't have experience with and don't find necessary, that advice becomes more prevalent.

[yrro]

Which is an excellent indicator that the following advice is bad.

[2OEH8eoCRo0]

Why is the Linux community full of horrible advice?

[not2b]

Often the issue is that what was decent advice five years ago can become horrible advice later, but the formerly decent advice is already moderated to the top on Stack Overflow and Reddit and is the first hit on a Google search, while the approach that people should be using now just isn't found.

You'll often find horribly complex multi-step instructions for How to Do X ranked more highly than simple instructions about how to use a new interface to do everything in one step, because there was a window of time when the complex instructions were required, everyone was so grateful for them and upvoted them.

[kobalsky]

you are also safe if you are not running (EDIT: inside) the container as root, which is a common security practice for containers nowadays.