this post was submitted on 03 Nov 2026
83 points (85.5% liked)
linuxmemes
33305 readers
323 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
- Don't get baited into back-and-forth insults. We are not animals.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry of any kind will not be tolerated. This is an LGBTQ+-friendly community -- if that is a problem for you, you should leave.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn, no politics, no trolling or ragebaiting.
- Don't come looking for advice, this is not the right community.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, <loves / tolerates / hates> systemd, and wants to interject for a moment. You can stop now.
5. π¬π§ Language/ΡΠ·ΡΠΊ/Sprache
- This is primarily an English-speaking community. π¬π§π¦πΊπΊπΈ
- Comments written in other languages are allowed.
- The substance of a post should be comprehensible for people who only speak English.
- Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
6. (NEW!) Regarding public figures
We all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations. - Keep discussions polite and free of disparagement.
- We are never in possession of all of the facts. Defamatory comments will not be tolerated.
- Discussions that get too heated will be locked and offending comments removed. Β
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
While the stock policies have been refined to model more of an average user's usage, the facility itself remains a PITA when people do trip over it. File operations that mess up contexts, use cases that don't quite fit the policy, use cases that are well recognized but SELinux blocks it by default anyway until you change an sebool.
By being a security mechanism bolted on after the fact, various operations fail in ways that are mysterious because they can't inject explanatory information into the failure path. Further the audit log that you pretty much always need to consult when something fails for mysterious reasons in case it might be SELinux isn't even readable by the user that got dinged. So I can't even code in a way to check if SELinux was the reason and guide the user, instead I have to provide a diagnostic utility they have to 'sudo' to explain to them, or be vague and say 'check if selinux is somehow involved. So I end up despite doing my damndest to not run with privilege asking users to run something with privilege to check a security mechanism.
The existence and usage of audit2allow is a big sign of problematic design. How to fix something you see in auditlog is hard for people to understand, so they just audit2allow to amend policy, but instead they should have done a
chconbecause now they have a crap rule allowing something they shouldn't, but SELinux is still enabled so all good!The whole label based concept is a fun whole other dimension of things for people to worry about. Messed up so often that we have a nice convenient 'restorecon' to basically apply the way AppArmor does things to the filesystem in that moment.
The curve could follow someone's journey with complexity, starting out with the prejudice that SELinux is bad, then letting SELinux happen and noticing no issues, and then moving on to realms where they actually have to touch the goop of SELinux instead of the canned distro SELinux setup covering their use case.
Over the last year I have done this entire. Went from app armor to SEL and now I'm back on app armor.
You couldn't pay me enough to try SEL again.
Yeah, AppArmor is a lot more straightforward. I could buy an argument that technically the SELinux approach is more flexible, but it's hard to imagine someone needing that much flexibility in the general use case.
I can understand why something like Android could get more mileage out of SELinux' model, but most scenarios are very capably modeled by AppArmor approach and much easier and less fragile functionality wise.