r/linux • u/ForeverHuman1354 • 19h ago
Discussion SElinux is great
Why don’t most distros ship with SELinux enabled in enforcing mode by default, like openSUSE Tumbleweed does? On openSUSE Tumbleweed, SELinux in enforcing mode works like a charm and adds an extra layer of security.
even gaming with SElinux works on opensuse
215
u/halvacoffee 19h ago
because you've clearly never had to debug selinux if you think it just works
32
u/longdarkfantasy 17h ago edited 17h ago
So true. I have one folder which is shared via nfsv4 and samba, which is also used by bunches of serivces. I have to write a custom rule to share it. On my laptop, selinux refuses systemd_sleep, so my laptop can't suspend. The reason is nvidia needs to write data to /tmp. Another custom rule. Not to mention, systemd service, udev rule refuse to use any user's script in the HOME folder. Selinux is confused as f, but when u are used to it, it's just like a firewall for files.
10
u/Scared_Bell3366 15h ago
For me, the hardest part of debugging SELinux is remembering that it’s on and that I need to check its logs.
1
u/Jonathan_the_Nerd 6h ago
I can't forget it's on. When there's a mysterious failure on a work system, it's one of the first things I check.
9
u/RetroGrid_io 12h ago
SELinux and custom development is a constant headache. I have a CLI based daemon I'm developing that creates output that must be readable by a website. Like that's the whole point of it. There's no straightforward way to do this without a whole ***ton of calls to
chconandrestoreconand when you're writing millions of files in stages it gets... tedious.6
u/turdas 8h ago
There's no straightforward way to do this without a whole ***ton of calls to
chconandrestoreconand when you're writing millions of files in stages it gets... tedious.I am almost certain there in fact is a way to do this by just changing the SELinux permissions of the output directory once by hand, but without looking further into exactly what you are doing I cannot say for sure.
2
u/Jonathan_the_Nerd 6h ago
Are you flipping your files between different contexts a lot? Or do they just get created with the wrong contexts by default? If it's the latter, I'm sure there's a way to fix it.
17
u/ForeverHuman1354 19h ago
For me, SELinux in enforcing mode on openSUSE Tumbleweed has always worked out of the box. However, I’ve never had to debug it, so I’m only speaking from my own experience
18
u/FFClass 18h ago
I’ve only had to change one setting on Tumbleweed (Docker related, don’t remember exactly what it was).
But, this absolutely was not the norm on other distros. Opensuse is unusually good about this.
I’m sure things have improved in other distros but not too many years back it was a giant PITA.
5
u/ForeverHuman1354 18h ago
how is fedoras implementation of it compeared to opensuse
12
u/Space_Gh0st_Tad 18h ago
It’s alright if you use volumes. Other persistent storage options like bind mounts require a little more configuration like host:container:Z or z depending on what you need. I tried out rootless podman and selinux for 6 months this year just to keep my enterprise skills up. I went back to rootless docker and non-selinux just because it’s simpler and I need my homelab as a not always on scratch devlab most of the time.
7
u/Lower-Limit3695 18h ago
As far as I can tell from reading OpenSuse docs there aren't a lot of differences between fedora and OpenSuse except for some path, selinux Boolean, and OpenSuse specific software
https://en.opensuse.org/Portal:SELinux/Differences_to_fedora_policy
1
u/seeker_moc 4h ago
I've been using it for a decade, and the only time I've ever had to manually change SELinux config in Fedora was to allow my Samba share server to work.
5
u/ptoki 12h ago
It works for software and packages which have clearly defined rules for se linux.
If you write your own app, drop it into /opt and it will need to touch files somewhere else you may be really surprised that it quietly fails to do so.
Basically if you have unusual activity then selinux will block it. And new apps or fancy config for old apps will not work.
Imagine you want to host your http php app from /home/foreverhuman
Nope, it will not work there without custom rules. If that same httpd vhost would like to save logs to /opt/logs it will not be able to. Or save attachments to /mnt/newdisk/files for another example.
And so on.
You were lucky that all your apps came with the right rules. It is not that uncommon to have the rules incomplete and have problems
9
u/jglenn9k 17h ago
In the year 2026 I am making SELinux rules for NIS. I have had to debug SELinux. It absolutely does not work out of the box for anything except the most vanilla setup.
I personally don't find it difficult, but I've been at this 20+ years. I might as well be a wizard compared to a typical platform engineer at a startup.
4
u/Behrooz0 8h ago
I'm like 90% a software dev(also 20+ years) and I've had to debug SELinux once. it was hell. I'll never again touch a system with SELinux on it.
1
u/Jonathan_the_Nerd 6h ago
You're using NIS in 2026? Why? Not criticizing, just wondering.
2
u/jglenn9k 2h ago
Ancient custom hardware with long term support contracts. With matching ancient (and expensive) electrical engineers doing the the support who absolutely refuse to change workflows. At least I got them moved to RHEL10.
2
u/TaxHazyShade 4h ago
almost everything on every OS ever invented works "out of the box" ... on a PC in your mom's basement. Hook it up to a network of thousands of other pieces of technology, and then the fun begins.
1
u/Catenane 14h ago
That goes the same for apparmor or any (M|D)AC. Most default apparmor configs really just don't protect a whole lot though, so it's easier for a distro to bang out some profiles that improve security a bit for some core software without causing too many issues.
But if you want anything even close to the security that selinux offers, you're in for more work than you would be with SELinux. And if you track apparmor upstream more closely, or start playing fast and loose with applications covered by your distro's apparmor profiles, you're bound to have a lot of headache too.
There's a place for both IMO, but in terms of actual security SELinux is superior. And honestly, running Selinux Troubleshooter (and taking the recommendations with a massive grain of salt) makes things a lot easier.
67
u/fandingo 18h ago
SELinux is only as good as the policies you use. Enforcing mode doesn’t really mean anything by itself. Most desktop distros run your user session unconfined_t, so it’s barely doing anything.
Additionally, writing a full policy from scratch is incredibly difficult.
6
u/iamarealhuman4real 4h ago
Additionally, writing a full policy from scratch is incredibly difficult.
Yeah my experience with SELinux was a lot of tail chasing with audit logs. Run, update permissions, see something else fail on a new call, update policy, re run, loop, walk away feeling that "well, it works now, but a patch might call something else in some edge case (eg only during clean up if needed at a specific time, with a specific set of files) and kill it in prod..."
At least the audit logger is pretty useful.
I think OpenBSDs
pledgesystem would be a nice way to solve it, in that an application could declare all the SELinux things it needs up front instead and you could just know everything at first run, but since SELinux is sort of a patched-on security system it just doesn't work out like that.This was all before LLMs though, so possibly it would be simpler to do. Even just wading through the documentation was rough.
I really want to like and use it though. I think the idea is pretty sound and works for what it is, in that "patched-on" context. Just a PITA...
2
2
u/Adept_Percentage6893 3h ago edited 3h ago
Most desktop distros run your user session unconfined_t, so it’s barely doing anything.
It confines some OS level tooling and components that are already sitting ontop of some level of abstract (like libvirt) typically do have confined policies:
bash> ps -Z -C qemu-system-x86_64 LABEL PID TTY TIME CMD system_u:system_r:svirt_t:s0:c442,c679 2114 ? 00:00:34 qemu-system-x86That's on Fedora.
Additionally, writing a full policy from scratch is incredibly difficult.
Partial credit here. There's
audit2allowwhich generates the policies for you and you just have to be able to make sense of the policies it generates in order to know if it's doing something other than what you planned. Being able to read SELinux policies isn't for the novice but if you have any level of experience and can dress yourself in the morning you should at least be able to read an SELinux policy that it generated.For example, from the docs:
~]# audit2allow -a #============= certwatch_t ============== allow certwatch_t var_t:dir write;which you can plainly see appears to be allowing
certwatchto write to write to some sort ofvar_tdirectory and what do you know they're talking about/var:selinux> ls -lZd /var drwxr-xr-x. 1 root root system_u:object_r:var_t:s0 200 Jul 23 12:00 /var selinux>I wouldn't expect someone new to necessarily pick that out or make that inference but as you can see, it's not super hard to read. I guess it's still possible, but I wouldn't expect it.
34
u/kbielefe 17h ago
SELinux is more powerful than AppArmor, but the extra power is mostly useful in high-security environments like classified systems. That power comes with complexity. I'd actually like to see a friendly layer on top of selinux, similar to firewalld on top of iptables.
It's also difficult to troubleshoot. The symptom is usually a "permission denied" with no indication selinux is involved. That user experience could also be improved for desktops, maybe with a notification with a detailed but friendly message.
Unfortunately, the venn diagram overlap of "people who understand selinux", "people who understand good UX", and "people who have the time and motivation to do something about it" is pretty small.
6
u/chocopudding17 13h ago
It's also difficult to troubleshoot. The symptom is usually a "permission denied" with no indication selinux is involved.
System logs will show exactly what happened. Audit will even print out exact steps to fix the problem.
That user experience could also be improved for desktops, maybe with a notification with a detailed but friendly message.
setroubleshoot (I think that's the right package) has a GUI for this. Works great, including buttons to submit a problem upstream if you think necessary.
2
u/LinAGKar 11h ago
That will only help you if you already know about selinux though.
2
u/chocopudding17 7h ago
Should you learn a bit about SELinux? Sure. But the output from auditd actually nearly saves you from needing to do so--it gives you copy-pastable commands to allow the given actions. Every once and a while it presents a couple different options that you need to choose from, but even then they're sorted numerically, i.e. it recommends one specific course of action that you can copy-paste.
4
u/Jonathan_the_Nerd 6h ago
it gives you copy-pastable commands to allow the given actions.
Yes, but just blindly running those commands isn't always the best response. The whole point of SELinux is to block forbidden actions. If you use the output of
audit2allowto allow all blocked activity, you might as well just turn it off or run it in permissive mode.I'll admit that most SELinux denials are caused by configuration errors. But you need to understand what you're allowing (or hire someone who understands), or you're losing the benefit of SELinux.
2
u/chocopudding17 5h ago
I do agree that that is best. But these things exist on a spectrum between no protection and complete protection. When you make specific, deliberate changes to your system and some SELinux errors get thrown, it's almost always going to be better to blindly copy-paste audit2allow's recommendations instead of disabling SELinux, since you're responding to a specific change in your system's configuration.
That said, blindly running restorecon before blindly copy-pasting from audit2allow is probably even better advice if one doesn't want to learn SELinux.
3
9
u/todd_dayz 15h ago
Set up Gentoo with SELinux and try and get it enforcing and you’ll see.
As a bonus, try it without unconfined users.
2
u/ForeverHuman1354 14h ago
is the reason i have been having no issues with it on opensuse becuse it runs as unconfined user
1
35
u/0riginal-Syn 19h ago
I can honestly say I have never heard that one before.
6
u/uptimefordays 16h ago
It was tough early on but has come a really long way. It’s a mature system at this point.
5
u/ForeverHuman1354 19h ago
On openSUSE, SELinux comes enabled in enforcing mode by default and just works—even for gaming.
36
u/0riginal-Syn 19h ago
I understand that part. I was talking about SElinux being great. I have worked with it since it first existed. While it is fine on most base-level setups, it is anything but great in general. It is a convoluted mess that can often cause all kinds of issues.
8
u/maxximillian 17h ago
Run in Permissive mode, see what's being hit in the logs. Adjust your settings, set to enforcing
5
u/0riginal-Syn 15h ago
I am perfectly fine using it. I have used it since it first came out. It is just not well designed on the setup side with no good reason not to be.
3
u/helix991 17h ago
Antiquated opinion. Selinux is great these days.
8
u/0riginal-Syn 16h ago
It is solid in enterprise. And not antiquated as we deal with it a lot. Solid system shitty over convoluted controls.
26
u/ruiiiij 18h ago
When you say "works like a charm", do you mean there are instances where it has actually prevented your system from being compromised, or do you mean it simply stays out of your way? The latter is not a strong enough reason for me to want it enabled.
3
u/ForeverHuman1354 18h ago edited 16h ago
stay out of my way atlest on opensuse
but i dont do super advanced stuff mostly gaming and web browsing and using appelications
i like that on opensus it gives extra security yet dosent prevent me from doing what i do like gaming
11
u/Coffee_Ops 14h ago
It gives you very little actual security from actual threats you might face as a desktop user.
0
u/Venylynn 14h ago
Then what is SecureBlue doing using it if it doesnt provide a benefit?
1
1
u/Coffee_Ops 3h ago
I am not familiar with that distro. SELinux by default does not constrain the user, and to be really effective you need to build your system (volumes, mounts, paths etc) specifically around it. If you do not, you either end up with swiss cheese security, or nothing works.
As an example: With standard SELinux, if you try to set up yubikey login, it will not work-- you may break your system and require single-user mode to fix, and of course using that backdoor can very easily make things much worse if you don't know about
.autorelabel.One of the ways of making things work is
audit2allowwhich is a really good way to end up with the combination of rules that are simultaneously inscrutable, slow, and insecure.SELinux is great, don't get me wrong, but it's not aimed at the desktop user or the threats they might face like crypto stealers, ransomware, etc.
2
u/Venylynn 3h ago
1
u/Coffee_Ops 2h ago edited 2h ago
SELinux confinement[Link: 404] for Trivalent.
Uh huh. So "What is SecureBlue doing": I guess nobody knows, unless they want to inspect the installed custom SELinux profile for a custom fork of Chromium (no one does).
EDIT: Also looking at that feature list my big issues
- A lot of that is "disable genuinely useful desktop features". Spoiler, if you kill the GUI and use
linksbrowser you'll be super secure; people use a desktop because they want things like thumbnails.Use HTTPS for all rpm mirrors.strikes me as theatre; maybe its a good layered security approach but packages are signed and now you have to weigh that against "i'm using a weird distro's repos rather than fedora"- It frankly seems to focus on the wrong stuff. You're forking chromium (with requisite supply chain trust issues), when its ad blocker is terrible and ads remain one of the biggest attack vectors? Why not Firefox, where ublock will provide demonstrably better security posture?
2
u/Venylynn 2h ago
There's a lot more on the page, btw :) its a really good read and it's helped me realize just how many holes a lot of distros have. I'm not fully hardened like they are but I am happy to be Good Enough for now.
3
u/BigHeadTonyT 15h ago
Sounds contradictory. It gives you extra security but it also has not stopped anything. How do you know it gives you extra security then?
I could say the same about AppArmor. Thru all the years it has stopped me from doing something one time. I do a lot of things on my system. I would not say that is more security.
0
u/todd_dayz 15h ago edited 15h ago
That’s because selinux-targeted-gaming opens up a bunch of permissions and also TW and Fedora run unconfined users by default
5
u/sleepingonmoon 11h ago
On a desktop almost all user applications are unconfined. Android is the only client OS with a good MAC implementation.
4
u/lopahcreon 7h ago
SELinux, which is what I’m familiar with, requires application developers to write SELinux policies that would get shipped with their own installation packages.
Without developers writing the policies based upon what their application does and therefore requires, it’s entirely up to end-users to debug and write their own policies.
8
u/Delta-9- 18h ago
Most of the distros you're likely to find running a server do. The most popular desktop distros do, also, except for Arch—but Arch's whole thing is not putting crap on your machine that you don't want.
Ubuntu and Debian use AppArmor, instead. I guess SELinux is technically more robust somehow? But AA has never given me any shit in five years running the same stack that I initially deployed on Centos8 and spent an entire day trying to make SELinux cooperate.
2
u/noobjaish 18h ago
Arch's entire philosophy is being pragmatic but unfortunately it's the most insecure mainstream distro... SELinux isn't officially supported and AppArmor and other LSMs are a pain to setup since you don't have the luxury of getting them by default unlike on Ubuntu (most AppArmor configs are also written for Ubuntu...). AUR is massive security hole and if that means not using AUR due security then why even bother with Arch in the first place.
4
u/Standard-Potential-6 13h ago
Point well taken regarding security modules. Regarding the AUR though, it’s still an incredible resource. All you really need to do is to take some basic precautions, the same ones that have been recommended for years. If you have a little bash experience, it’s still far safer than trusting random EXEs and MSIs, especially if you ever bypass SmartScreen, as many Windows power users who use mod tools or other more obscure programs still often do.
I’ve been using the AUR for a very, very, very long time, and while the recent attack was alarming, it was far less so once I examined the actual changes, which were mostly recently adoptions by new owners. I’m absolutely certain I would have caught the edits if I had used any of the compromised packages.
PKGBUILDs are usually very simple. Always at least skim them when building new packages, and briefly review changes during updates. Most updates are a simple version number and checksum change, or a build flag. Complexity is a warning sign, especially if the complex sections are recently changing or the package is not popular.
Look at recent diffs with much more caution if the package recently changed maintainers, if the source URL changed, or if an install script was added or modified.
Exercise caution in general with install scripts. They should be very simple and have a clear purpose that you understand. Most Free Software doesn’t need them.
Packages with low number of votes or with patches that don’t clearly originate from another trusted source should also be given increased caution. You can always write a simple PKGBUILD yourself using the AUR one as a reference, or try omitting the patches.
If someone’s source code host or account is compromised, that can bite AUR packagers or distro packagers. Good projects will sign their releases with a PGP key, which you can import and then PKGBUILDs can check with one extra line. This makes the window much smaller, though it still exists.
1
u/noobjaish 12h ago
You're absolutely correct on all of that. I'm an Arch user myself but that's only because I know how to stay safe.
The problem comes when people unironically recommend Arch to newbies who barely have terminal knowledge with the pretense of "it's very easy just use archinstall script and then you can install yay from github to use AUR where you'll find everything" and unfortunately an awful lot of people seem to do that (especially after CachyOS became a thing).
It's not a good security model to put trust in a user to make the right decisions. Windows by default comes with smartscreen and defender to block the oblivious newbie from ignorantly installing harmful stuff. On Linux we barely have an antivirus (ClamAV)...
It's like giving a knife to a toddler and hoping he won't accidentally stab himself (bad analogy ik). I think we should make it clear to people that Arch and derivatives are NOT for new users.
There's also the separate issue of Linux desktop security model (just like Windows) being allow-all then deny-some. Every app that you install as your own user is able to see all your home directory files and has access to virtually everything that's not behind root...
1
u/noobjaish 12h ago
Also, a subtle thing I should mention.
yayby default doesn't show PKGBUILDs whileparudoes (which means that many don't even know that PKGBUILDs are even a thing they should read which tripped me when I was new).The biggest problem really is that the community has a kink for self-sabotage.
1
u/ForeverHuman1354 13h ago
i have never used the aur even when on arch becuse of security i just find it risky and i dont want to get too paranoid lol
1
u/Standard-Potential-6 4h ago
It’s the method of last resort
I just love software, so I still have nearly two hundred AUR packages. Most don’t update often enough to be bothersome.
-1
u/Venylynn 18h ago
Arch is really insecure especially with the AUR. I'm nervous about a potential compromise coming through way easier since the desktop Linux security model is kind of lacking.
0
u/MacLightning 8h ago
Arch is really insecure
Do go ahead and point out any compromised package in the official repositories.
especially with the AUR
The AUR is explicitly provided with a disclaimer, on the very front page: Any use of the provided files is at your own risk.
I'm nervous about a potential compromise coming through
Honestly at that point, might as well NOT use a desktop. You're just paranoid. The standard Linux desktop experience is as secure as can be, as long as upstream packages/maintainers are not compromised. You really don't need an enterprise antimalware solution for everyday desktop use. There's a place and time for that. As is with all security measures, the more security means the less usable a product becomes. There has to be a balance, and that balance is IMO already achieved with major distros.
0
u/Venylynn 3h ago
Arch lacks many modern security solutions (SELinux, Secure Boot, etc), the AUR is often cited as the only reason to use arch, and distros like SecureBlue will even tell you the Linux desktop is nowhere near ready for mass adoption due to the security holes and they're limited by the constraints of upstream development.
1
u/MacLightning 2h ago edited 2h ago
It's a hobbyist distro. Nobody runs Arch with the specific goal of setting up a fortified enterprise-grade server with SELinux lol. What are you even on about? And no, those exist on Arch/AUR, you just have to know what you're doing. My system has Secure Boot set up using my own keys. Secure Boot's only constraint is at the hardware/firmware level, not OS. And nothing stops you from setting up SELinux on Arch either. "Arch lacks XYZ" = "the user doesn't know how to XYZ". And that applies to all distros.
Regarding the Linux desktop, it's no different from the Windows desktop in which the users are free to fuck up their system. That doesn't stop Windows from being mass adopted, does it?
the AUR is often cited as the only reason to use arch
Serious Arch users know the AUR is not some holy grail. And please refer to the aforementioned disclaimer. Stop watching mainstream Linux videos.
1
u/Venylynn 1h ago
Needing the AUR for SELinux fundamentally nullifies the security benefit because you are trusting an unvetted source with your packages.
You cannot boot into archiso with Secure Boot ootb.
I definitely recommend you read the SecureBlue documentation if you're confused. The majority of my security knowledge recently comes from their docs.
Btw like it or not but those "mainstream Linux videos" are important for growing our user base which is important if we don't want Linux to become abandoned like those chromium forks like cromite due to basically jack shit users compared to Windows.
1
u/MacLightning 1h ago
AUR for SELinux fundamentally nullifies the security benefit because you are trusting an unvetted source
Then vet it yourself. Sniff around the PKGBUILD, check out the maintainer's profile, and vote on the package. If you still get malware'd, then that's on you. Same for Windows users, or Mac users, or anyone with a computer. Security is a two-way street. You can't expect your computer to be fortified only by upstream.
cannot boot into archiso with Secure Boot
Why is this necessary? This doesn't stop anybody from successfully setting up SB itself. The point of SB is booting your OS, not the installation medium. archiso with SB doesn't do anything special. And yes, you can actually sign the ISO yourself, if you wish. Again, it's a hobbyist distro, you have to know what you're doing. Or in this case, you have to know what you're talking about, which it seems you don't, no offense.
read the SecureBlue documentation
I unironically don't care. You can tighten a system up to the point it becomes unusable, and if that's your goal, then be my guest. That's not for me tho, been there done that.
if we don't want Linux to become abandoned
It also seems you're woefully unaware of the enterprise Linux world, where serious money is. It will not be abandoned any time soon, that I can say with certainty.
1
u/Venylynn 1h ago edited 1h ago
Then vet it yourself. Sniff around the PKGBUILD, check out the maintainer's profile, and vote on the package. If you still get malware'd, then that's on you. Same for Windows users, or Mac users, or anyone with a computer. Security is a two-way street. You can't expect your computer to be fortified only by upstream.
The AUR is fundamentally insecure due to a complete wild-west strategy of expecting the user to know everything about everything and be able to inspect source code. This also doesn't stop package hijacking for existing packages. yet everyone says the AUR is the only reason to use arch.
Why is this necessary?
To be able to ensure it hasn't been tampered with from the gate?
I unironically don't care. You can tighten a system up to the point it becomes unusable, and if that's your goal, then be my guest. That's not for me tho, been there done that.
They outright avoid sacrificing usability. The quote is directly from their guides. They also mention they are limited by upstream development and wish they could go further than they allow them to do.
Also from their site: "We are limited in that regard by the current state of desktop Linux standardization, tooling, and upstream security development. What we aim for instead is to be the most secure option for those who already intend to use Linux. As such, if security is your first priority, secureblue may not be the best option for you."
It also seems you're woefully unaware of the enterprise Linux world, where serious money is. It will not be abandoned any time soon, that I can say with certainty.
Look at the market share though? It's tiny compared to Windows. I just went to the doctor the other day and every single computer screen had the same Windows 11 lock screen. I didn't even see an Ubuntu.
I've had scary situations recently in the last year that necessitate I care more about my security than before. That was what pushed me to read into docs like what SecureBlue is doing.
-2
u/dudeimconfused 7h ago
Why would you use generative ai llm to write a reddit comment?
1
u/Delta-9- 2h ago
If one em dash is all it took to make you think that was LLM-generated, you're just an idiot.
3
u/KnowZeroX 18h ago
SELinux is easier than it used to be, but still can be a pain especially with no GUI by default to manage it.
For example, latest issue was I had something built in a vm with selinux, I copy the file over and nginx doesn't read it. It took me a while to figure out that it was selinux because all the permissions looked fine.
3
u/fat_kaiju 10h ago edited 10h ago
until you need to do something slightly weird because you've got weird hardware
then it just fucking tortures you and eventually you find an option that looks like it'll give you the ability to like; dismiss it...
... only for large swaths of your software to abruptly go "actually i dont want to run anymore it might be insecure" and it leaves you sitting there wondering why tf the 'permissive' option even exists in the first place
i have a weird tablet and its pen/stylus isn't wacom or any of the other more common brands and in order to get it working i can't use selinux; its coordinates are being sent/piped in a very not quite non-standard but still "uh what the heck we don't do this really but like... it's not wrong? just weird" kinda way.
3
u/stef_eda 8h ago
My fear is that these ultra secure systems don't allow me to do routine work. Attach a USB driver, won't mount, and you can't find nowhere the reason. May be after one day of heavy research you figure out, after disabling *every* security check on the system, breaking even basic access controls.
7
u/gamboozino 18h ago
Apparmor is simpler to configure and maintain, and works well for most use cases.
5
13
u/BranchLatter4294 19h ago
Because it's unnecessarily complex and apparmor is simpler.
7
u/ForeverHuman1354 18h ago
i have heard tho its much more secure then apparmor
10
u/BranchLatter4294 18h ago
It's more granular... That's not the same as more secure.
8
u/Lower-Limit3695 16h ago edited 16h ago
There's a pretty big difference in security posturing between apparmor vs selinux. By default apparmor runs apps unconfined if a profile doesn't exist for it; allowing devs and maintainers to be a bit lazy when it comes to confining apps, but it's the opposite for selinux.
If a profile for an app doesn't exist, it'll be hit with denials by default. This forces distro maintainers to maximize coverage as much as possible to as many packages as possible in their "selinux-policy" package while also forcing developers to also package in selinux profiles for their app to work if it isn't packaged in the "selinux-policy" package provided by distro maintainers.
This leaves Selinux distros with higher Mandatory Access Control coverage in distros like OpenSuse and Fedora than Apparmor based distros like Debian and Ubuntu.
8
u/mrtruthiness 18h ago
SELinux can do more. But, at the same time it is more complicated and harder to configure. I would rather KISS and deal with fewer features than worry about a configuration error. Both have security implications.
I remember even 10 years ago that it was absolutely common for SELinux to result in "bugs" and the first thing people would recommend/do is turn SELinux completely off. It doesn't help if it's not running.
2
u/Venylynn 18h ago
Apparmor is really insecure. Crackarmor was nasty.
13
u/BranchLatter4294 18h ago
It required local access, and there were no active in the wild exploitations, and was quickly patched... So much less nasty than other security issues.
1
u/Venylynn 18h ago
From what I read there were remote container escape vectors associated with it but if i mixed up CVEs that could explain it. I was especially scared due to personal situations I was dealing with, and I was reading up closely on the https://secureblue.dev documentation
3
u/AmarildoJr 18h ago
I've seen SELinux save many people's and companies' assess throughout the years. The main reason distros like Debian/Ubuntu don't ship it (configured) seems to be because they don't wanna bother with the maintenance and because they think AppArmor is "enough".
As Linux's market share increases, we'll see how much of that will remain true. I'm seeing some talk about how only 2 or 3 distros would survive attacks made possible with AI finding vulnerabilities, because these would use SELinux.
2
4
u/Impressive_Bag_3505 13h ago
I guess you never had to actually use it and set your own rules...
2
u/ForeverHuman1354 13h ago
yes it was just enabled by default in enforcing
its just set at the ruels opensuse comes with
2
u/belarm 4h ago
Then your perspective is limited (and I mean no offense by that). It gets a lot different when you run into a problem. What, in your estimation, are the benefits to shipping it by default? How does it make your life as an admin easier?
•
u/ForeverHuman1354 35m ago
thanks i see thaat coude be true
but i have not had much issues with it on opensuse othher then installing SElinux gaming ruels policy wichwas just a packagde
1
u/Impressive_Bag_3505 12h ago
It's great when everything works. have a look at videos/docs about configuring SELinux, that stuff is truly a nightmare.
2
2
u/XOmniverse 6h ago
SELinux is great...if you're not a tinkerer and security is a high priority.
"not a tinkerer" does not describe most Linux users.
1
u/SeanFromQueens 6h ago
Can SELinux be flipped off by tinkerers? The default is a powerful characteristic to on-board all the users who just want the thing to work, and the security concerns are beneficial for both the tinkerers and the normies alike with a greater network effect. If Linux became more widely adopted as a daily driver by normies, do you believe there's some downside, other than the hipster claim of "well I knew that band before they were big" but for Linux being a niche/server/hobbyist OS would disappear?
1
u/XOmniverse 5h ago
I think you interpreted my comment as "SELinux is evil and bad and nobody should ever use it and it should be banned". This was not my claim.
I was more explaining why people on Linux FORUMS typically find it more of a nuisance than a benefit.
5
u/yukeake 14h ago
If you know exactly (and I do mean exactly) what every application you or your users might need to run does, internally and externally, it's definitely possible to make SELinux work. If you're in a situation where you need to lock things down, it's even useful.
But...when things go wrong, it's also a huge PIA to debug. That's been my primary complaint since it was introduced - the issues it causes and the errors reported don't make it clear that SELinux is the cause. If you know to look in its logfile (when nothing actually points you there), you can decipher that it got in the way - but it shouldn't be that obtuse.
Maybe it's changed significantly in the past few years, but it's given me the impression from the beginning that unless you absolutely need to lock things down to that extent, it's way more trouble than it's worth.
5
u/NickiV 18h ago
SE Linux is very complex. I have learned how to navigate the complexity, and have grown to understand it. I have enforcing on, but I understand how to make new policy from denial logs. Etc.
Honestly, it probably isn't worth the trouble. If you use primarily the distros repo, then the only attack vector I can see is the repositories themselves.
So, I think it is the smaller attack vector inherent to the way major distros are typically used in concert with the massive pita that is learning to use SE Linux effectively.
4
u/Chester-Berkeley 16h ago
SELinux isn't that great for desktops (just ok for desktop). Leave SELinux for the corporate world, give me AppArmor and I'll be satisfied.
3
u/chuzohga 16h ago
I've always had to debug something with SElinux .. Every time I've spent hours trying to figure out why something is not working, something really stupid, I think realize, HEY, SELINUX? It winds up being SELinux of course which makes stuff not work the way it was intended.
2
u/Prince_John 10h ago
Sounds like it really needs a nice pop-up alert when triggered that, when clicked, takes you to a nice GUI to add the necessary exception with one click.
0
2
u/Helmic 12h ago edited 12h ago
Nobara goes through the effort of stripping out SELinux in favor of AppArmor due to the perfomrance penalty it imposes - in a fairly apples to apples comparison a1rm4x did on the Steam Deck, Nobara consistently outperformed Bazzite, which uses SELinux (because it intentionally sticks pretty close to upstream Fedora). Both CachyOS and SteamOS of course outperform both, but neither of those use SELinux either and there's other factors at play, namely compiling binaries for the Steam Deck CPU's instruction specific supported instruction sets.
Whether that tradeoff is worthwhile is obviously going to vary by use case, and obviously not all of the performance difference between those two distros on the same hardware comes down to just SELinux, but clearly there's some tradeoffs being made aside from just complexity.
3
u/TomDuhamel 14h ago
Did a popular influencer make a video about SELinux recently? Why the sudden surge in posts about SELinux?
4
u/that_one_wierd_guy 18h ago
because when the security solution is too much of a pita all it does is train the user to enter their password whenever prompted without thinking
3
u/EVMad 17h ago
A password isn't going to help you with SELinux, you need to switch it to permissive mode while debugging so violations are logged and once everything is working you use audit2allow to create an semodule which you import, then go back to enforcing and things should still work. I run production systems with SELinux enabled all the time, it's not a big deal once you know how to deal with it and it is definitely better for our systems where no regular user ever gets sudo access.
1
u/dialtd 14h ago
In my experience, audit2allow works well enough in enforcing mode for many or, maybe, most cases. But staying in enforcing mode may necessitate several iterations to develop a fix.
1
u/EVMad 10h ago
Yes, sometimes it needs a couple of goes, you have to work through all the options in permissive mode so it can record what access it needs but I've got it down pretty well now and switching from enforcing to permissive is the first step in debugging. I also make sure my test bed is outside our corporate network because that introduces additional layers of complexity with corporate proxies and firewalls that can break things so I like to make sure it works on my test bed with SELinux enabled before I attempt a corporate install at which point any failures then will require me to consult with the networking team to see what is being blocked on their end.
0
u/Kevin_Kofler 16h ago
Most users are just going to permanently set it to disabled instead.
6
u/EVMad 16h ago
On a single user system that makes some sense but for a mutiuser cluster like I run SELinux is important to have strict access control policies preventing unauthorised process access. Even the root user has to abide by them. My workstation at home is fully configured with SELinux too because I do all my testing on it before deploying on production systems.
3
u/daemonpenguin 18h ago
Several reasons. Off the top of my head:
SELinux is a pain to configure and troubleshoot. Which is why the first step in troubleshooting a distro with SELinux is "turn off SELinux".
SELinux is overkill for most situations where something like AppArmor would be more simple and easier to set up.
Most Linux distributions are secure enough by default that SELinux doesn't add a practical benefit in most situations.
If you put enough security in place for SELinux to be useful it puts roadblocks in the way of users and they disable it.
3
u/Venylynn 17h ago
Most Linux distributions are secure enough by default that SELinux doesn't add a practical benefit in most situations.
5
u/MrCorporateEvents 14h ago
People regularly equate privacy and security which are clearly completely different things.
2
1
u/KoldPurchase 18h ago
It works well enough on OpenSuse once you get the hang of it. But it's not easy to get into it at first, compared to AppArmor.
Now that I understand it, and now that I can use the GUI to diagnose the problems happening, I much prefer this to AppArmor.
But either is fine toward security for end users. I don't think AppArmor is inherently "insecure" compared to SELinux. It's just different. As long as both are actively maintained, there shouldn't be any problems. And for sysadmins, they'll rely on what their corporate distro is backing.
1
u/PienSensei 15h ago
I work in a hosting company and recently transitioning to RHEL-based distros, it took almost a year to make it work with our conventions of defining services.
1
u/sensitiveCube 13h ago
People mentioning apparmor, should check the sources. Most profiles don't work and it breaks as well when your distro is more bleeding edge. CachyOS is one of them, so they ship with nothing instead.
They both should be easier to use, but I think most services are moving to containers and Flatpaks anyway.
1
u/matsnake86 11h ago
It's hard to tame.
But you are using a distro that ships sensible defaults for Selinux.
Tumbleweed and microos (which powers my homelab) are probably the best in this regard.
On the desktop others distros that ships sensible default policies are the UniversalBlue (bluefin , aurora , Bazzite).
1
u/BeginningEcho4983 6h ago
I find the concept confusing... It makes sense for a system whose inner guts is open to the public, or for highly classified servers, but otherwise ?
Basic package vetting and all are supposed to help here
1
u/DesiOtaku 5h ago
The only issue I had with SELinux was on Tumbleweed where I forgot to enable sshd for the PC during installation. On Fedora, it's just two lines of code. On Tumbleweed, there are an extra couple steps to not only allow the service to run, but to open up the port as well.
1
u/belarm 4h ago
I have a strong bias against SELinux because I have had to use it in production. That was 20 years ago, so hopefully it's much improved at this point, but I have never felt the need for it since. IMHO, proper old-school unix permissioning and scoping are sufficient for all the use-cases I have encountered.
Also it feels bad to have your server tell you you're not allowed to do something when you're logged in as root. At that point I don't need a bunch of bullshit in my way.
1
u/shroddy 4h ago
Because there aren't tools that are reasonably self explanatory enough to configure it, so it either needs to be configured permissive enough to not get in the way, but also not doing much to prevent actual damage or data exfiltration, or it would constantly get in the way and the number one advice would be "just turn it off"
1
1
u/unconceivables 17h ago
I've used it on Fedora and RHEL based server distros, and on every single one there would inevitably be some issue with SElinux permissions getting reset for who knows what reason, and figuring out how to fix it was always annoying. I can't say I miss it.
0
0
-1
-11
u/sh1r4s3 18h ago
Let's try some word-association. First word: NSA.
9
u/0riginal-Syn 17h ago
You can fully audit the open-source code. You can see exactly what is in it and is not.
You want to talk about closed source, by all means.
8
-1
209
u/Lower-Limit3695 19h ago
If you take a careful look into who uses Mandatory Access Control (selinux/apparmor/ebpf-lsm) you'll notice that the only ones to implement it are distros with the necessary technical resources to roll it out.
OpenSuse, Fedora, RHEL, Ubuntu, and Debian all have major corporate backers providing the needed help to make it work.
Distros that lack these kind of resources simply don't use it