The problem with SELinux is it's very fragile and basically broken outside RedHat distros.
As an experiment I installed SELinux on Debian and while I was eventually able to get it stable and working after a lot of trial and error, a disk swap followed by an rsync broke it irreparably. Yes I rescanned the disk or whatever to have SEL relearn/reindex the objects, didn't work. The box was basically unbootable or it would boot and rejected all logins, including root directly to the console, something that should nearly never happen. Documentation is sparse or assumes you have RedHat and it 'just works'. After hours of troubleshooting the only thing that worked was switching it off and saying good riddance.
It's also my experience that Fedora has better support for it, but Gentoo used to be good enough with hardened gentoo (they use https://gitweb.gentoo.org/proj/hardened-refpolicy.git/). Redhat and Gentoo are the only ones that officially support it afaik. I think hardened gentoo might have lost popularity since the fall of grsec, but I'm not sure how popular it is currently.
Gentoo added some excellent and fairly distro-neutral documentation for SELinux a few years ago which makes it somewhat viable outside of Red Hat. It's also helpful for debugging issues even on Red Hat.
It's unfortunately "broken" on purpose even on RHEL. Red Hat have made decisions to run init services in unrestricted context just to make it easier for their end clients to deploy their own services without needing SElinux modules.
In my view all these compromimses only speak to the true security of SElinux. The fact that we need to have a website called https://stopdisablingselinux.com/ means it's working!
I am one of those weirdos who prefers to learn and adapt to SElinux instead of disabling it.
The article in question takes a lot of liberties with complete FS access. It's not really applicable to real world server security. The focus is on smartphones.
Mh. I know Linux and SELinux. SELinux has a severe documentation issue.
Like, as a user, once you grok filesystem, port and process tags, it's easy to navigate most if not all common "strange" SELinux errors.
After that I figured, I might be able to implement SELinux modules for our in-house services. Just tag config files, binaries, logfiles, state files, add a tag for the process, link them up with a few rules, easy peasy
I all in all hit a wall harder than the iron curtain. I'd have to understand my application on an individual syscall level (I think, from like one github gist and a random dudes blogpost going into a few details to implement selinux modules) to do anything at that level. I spent a week on that and figured that I either have to understand kernel interfaces and the entire SELinux stack in all details to implement my own SELinux modules, or to not implement my own SELinux modules.
At that point I figured no one else on the team would have a snowballs chance in hell to do any of what I'm looking at and accepted SELinux would not be a thing for our internal applications.
SELinux for Linux was never intended to be highly secure. When NSA created it [1], the intent was to get user software modified to work in a mandatory access control environment.
Then, more secure operating systems for DoD use would be able to run available software.
NSA used to do a lot of operating systems work, but no longer seems to do that.
.. a flexible MAC architecture was created and matured through a series of research systems. The work to bring this architecture to mainstream systems [and] experience with applying this architecture to mobile platforms is examined. The role of MAC in a larger system architecture is reviewed in the context of a secure virtualization system. The state of MAC in mainstream systems is compared before and after our work.
We describe our work to demonstrate an enhanced SMI transfer monitor (STM) to provide protected execution services on the x86 platform. An STM is a hypervisor that executes in x86 system management mode (SMM) and functions as a peer to the hypervisor or operating system. The STM constrains the SMI handler, by hosting the handler in a virtual machine (VM). Otherwise, the SMI handler holds unconstrained access to the platform, which could undermine the assurance provided by DRTM or TXT.
I really wish they resume their (visible) work on Operating Systems; if nothing else, it signals the world that OS Security is "serious business" when the premier cyber-spy-security agency dedicates resources to it. I cannot believe they are strapped for money!
RH is doing a lot of good things like unifying the NetworkManager configuration for plugins. But some things give me pause, such as - and it's been a while so I don't quite remember - copying ssh key selection settings to a security policy file elsewhere such that those settings in the regular config would be ignored. These are ssh-specific settings that did not integrate into a global "policy", and which were placed in a nonstandard location - not ssh.d, which now that I think about it is probably another RH invention.
Annoying until you learn to disable it or learn what it is good for and how to configure it so that it will work for you.
It's annoying because it's a change in system that you are familiar with and you can trip on it you if you are not familiar with it, not because it is not useful or great challenge to configure right.
> But some things give me pause, such as - and it's been a while so I don't quite remember - copying ssh key selection settings to a security policy file elsewhere such that those settings in the regular config would be ignored.
Yeah, I've always been against that type of crap.
It's why Ubuntu, even Debian, and especially RedHat were never really viable distros for me when things like Slackware, Alpine and Void exist.
I don't need a ton of abstraction between me and what I'm trying to accomplish.
By default, packages you install from the OS have SELinux labels set for correct operation, and sometimes have booleans you need to enable to allow more advanced use. Anything you install yourself (e.g. tarballs) are completely unrestricted. It sounds like you need to get a better understanding of where the lines are.
When I used Fedora for desktop, VS Code triggered warnings because of a SELinux configuration. Something about using writable memory as executable.
The discussion on the topic was disappointing. Chrome does this, all Electron apps do this, VS Code does it. It was insisted that the warnings were fine because this is insecure and the developers should just fix their applications.
I do not have the patience to waste two hours researching every single complicated solution that every single application uses to make things work just to personally decide whether it's safe enough to whitelist it.
Pointless warning spam drowns out real issues in the logs all the time. You cannot expect an end user to fix chromium based applications or stop using them, so all you end up doing is making the system less usable and less secure.
There are two components to SELinux alerting mechanisms, both of which are documented.
For GUI notifications open the sealert app and disable alerts. For journal/syslog reports disable the setroubleshoot daemon dispatch plugin for auditd:
sed -i 's/active.=.yes/active = no/' /etc/audit/plugins.d/sedispatch.conf
service auditd restart
You can also uninstall the setroublshoot-server package completely, and all AVC denials will continue be reported separately outside of the journal.
Sure, but even disabling SE Linux all together seems like a lighter and more sensible solution to me than changing distros. I doubt those applications are suddenly going to stop doing the things deemed insecure because they're running on a different distro, so even just allowing those actions seems far easier and still better off than changing distros. I generally try to fix all SE Linux issues as they come up, but when I just need something working and don't have time to muck with it, I've disabled it in the past. Yes, I know it makes Dan cry, but having people screaming for something that they need immediately to do their jobs makes me cry.
No, I actually tolerated it for a long time before switching. What made me switch was that Fedora became so horrendously slow that it took 15 minutes just to open a web browser. I even tried launching things with syscall tracing but the output just literally froze mid-line all the time while the system was writing to disk. Even though my RAM was mostly unused, it just kept freezing all the time.
This is a problem in ALL linuxes as far as I know. When Linux gets IO-bound, literally everything gets stuck and it's insane. My mouse cursor position doesn't depend on my hard disk. I have a dozen cores. I don't understand. I thought this kind of issue was solvable on a single core with just a round robin scheduler. How come things still get stuck?
It could be that the problem was that I installed every DE I could find to test them, but even after uninstalling a lot of things, the system never recovered its original speed.
I installed Linux Mint on the same hard disk and things run smoothly. In particular, I love how Cinnamon actually keeps the list of applications in memory instead of starting a search every type I open the start menu. The DE has its shortcomings but it's pretty decent otherwise so for now I'm happy with it.
P.S.: also when I tried to use git with apache, checking out overwrote my SELinux types and contexts, which meant I had to figure out AGAIN how do configure all this stuff just so I could access a wordpress site in localhost that was saved in my home folder. For a while I just gave up using branches in git. Now I just use Mint.
I’ve had that POS SELinux block me from logging directly into the console with root (nothing wrong with the pwd). Thank VMware for snapshots. I hate SELinux.
But the job requires it.
As for people who seem to love it so much, they probably don’t have to deal with it all the time.
The problem is that when people don't know how to use it and instead turn it off they're immediately deluged from every side with pathetic nerds screaming that YOU DONT HAVE TO TURN IT OFF ANYMORE RUN THIS ARCANE SEQUENCE OF COMMADS THAT YOU DONT UNDERSTAND AS ROOT AND THAT WILL FIX THE ONE ISSUE YOU HAVE without understanding that not every computer system needs to be locked as tight as a server that's being shared with a bunch of untrusted users who are running god knows what.
Followed by "surely the year of the Linux desktop is at hand!"
I'm not going to link it here given his disdain for this site but jwz at least got the CADT development right. If you stop fucking rewriting things every couple of years then maybe the average user could catch their breath and catch up but if you keep changing things that don't need changing (ALSA -> PulseAudio -> pipewire -> whatever is already in the works to replace pipewire) instead of ACTUALLY FIXING THEM then you lose the right to be surprised when someone just trying to use their computer just gives up.
The problem with SELinux is it's very fragile and basically broken outside RedHat distros.
As an experiment I installed SELinux on Debian and while I was eventually able to get it stable and working after a lot of trial and error, a disk swap followed by an rsync broke it irreparably. Yes I rescanned the disk or whatever to have SEL relearn/reindex the objects, didn't work. The box was basically unbootable or it would boot and rejected all logins, including root directly to the console, something that should nearly never happen. Documentation is sparse or assumes you have RedHat and it 'just works'. After hours of troubleshooting the only thing that worked was switching it off and saying good riddance.
Most distros use https://github.com/SELinuxProject/refpolicy while RHEL uses https://github.com/fedora-selinux/selinux-policy
It's also my experience that Fedora has better support for it, but Gentoo used to be good enough with hardened gentoo (they use https://gitweb.gentoo.org/proj/hardened-refpolicy.git/). Redhat and Gentoo are the only ones that officially support it afaik. I think hardened gentoo might have lost popularity since the fall of grsec, but I'm not sure how popular it is currently.
FWIW Android also uses SELinux & I believe selinux-policy. Have no idea about the quality of the implementation.
>Android also uses SELinux
Too bad you haven't even read a part of the article.
I was responding to what OP wrote:
> Redhat and Gentoo are the only ones that officially support it afaik
Gentoo added some excellent and fairly distro-neutral documentation for SELinux a few years ago which makes it somewhat viable outside of Red Hat. It's also helpful for debugging issues even on Red Hat.
https://wiki.gentoo.org/wiki/SELinux
It's unfortunately "broken" on purpose even on RHEL. Red Hat have made decisions to run init services in unrestricted context just to make it easier for their end clients to deploy their own services without needing SElinux modules.
In my view all these compromimses only speak to the true security of SElinux. The fact that we need to have a website called https://stopdisablingselinux.com/ means it's working!
I am one of those weirdos who prefers to learn and adapt to SElinux instead of disabling it.
The article in question takes a lot of liberties with complete FS access. It's not really applicable to real world server security. The focus is on smartphones.
Mh. I know Linux and SELinux. SELinux has a severe documentation issue.
Like, as a user, once you grok filesystem, port and process tags, it's easy to navigate most if not all common "strange" SELinux errors.
After that I figured, I might be able to implement SELinux modules for our in-house services. Just tag config files, binaries, logfiles, state files, add a tag for the process, link them up with a few rules, easy peasy
I all in all hit a wall harder than the iron curtain. I'd have to understand my application on an individual syscall level (I think, from like one github gist and a random dudes blogpost going into a few details to implement selinux modules) to do anything at that level. I spent a week on that and figured that I either have to understand kernel interfaces and the entire SELinux stack in all details to implement my own SELinux modules, or to not implement my own SELinux modules.
At that point I figured no one else on the team would have a snowballs chance in hell to do any of what I'm looking at and accepted SELinux would not be a thing for our internal applications.
SELinux for Linux was never intended to be highly secure. When NSA created it [1], the intent was to get user software modified to work in a mandatory access control environment. Then, more secure operating systems for DoD use would be able to run available software.
NSA used to do a lot of operating systems work, but no longer seems to do that.
[1] https://www.nsa.gov/Research/NSA-Mission-Oriented-Research/L...
MAC for Zephyr was presented at Linux Security Summit (2019), https://www.youtube.com/watch?v=AKWFbxbsU3o
Review of non-public STM for constraining SMM, https://www.platformsecuritysummit.com/2018/speaker/myers/ OSS STM contributed to coreboot, https://cyberscoop.com/nsa-firmware-open-source-coreboot-stm... & https://www.osfc.io/2019/talks/implementing-stm-support-for-...I really wish they resume their (visible) work on Operating Systems; if nothing else, it signals the world that OS Security is "serious business" when the premier cyber-spy-security agency dedicates resources to it. I cannot believe they are strapped for money!
Crowdstrike provided everyone on the planet with a very strong signal of the the importance of OS security
I'm a bit confused by this article. If you have a way to write arbitrarily into kernel structures can't you pretty much do anything already?
On raw hardware, yes, but they're talking about running on a Samsung hypervisor.
Where does the kwrite() come from? How do you get the privileges to write to arbitrary memory addresses?
It seems to me that every new rhel release has more switches to throw to get my things installed and working.
It's especially a bit extreme when systemd gets the syslog denial.
How do we dial this back?
Learn RHEL properly or use a different distro. RHEL isn't going to change its philosophy.
You are being downvoted but this answer is exactly right. It's kind of like complaining about group policy in Windows.
That's exactly right - RH is windozifying Linux.
So is Ubuntu, so is any distro with systemd.
The point though, was if you don't want to learn to use a complex system you shouldn't complain when you use it and don't understand it.
RH is doing a lot of good things like unifying the NetworkManager configuration for plugins. But some things give me pause, such as - and it's been a while so I don't quite remember - copying ssh key selection settings to a security policy file elsewhere such that those settings in the regular config would be ignored. These are ssh-specific settings that did not integrate into a global "policy", and which were placed in a nonstandard location - not ssh.d, which now that I think about it is probably another RH invention.
Similarly, how having systemd-resolved running overrides /etc/resolv.conf. Pretty annoying.
Annoying until you learn to disable it or learn what it is good for and how to configure it so that it will work for you.
It's annoying because it's a change in system that you are familiar with and you can trip on it you if you are not familiar with it, not because it is not useful or great challenge to configure right.
> But some things give me pause, such as - and it's been a while so I don't quite remember - copying ssh key selection settings to a security policy file elsewhere such that those settings in the regular config would be ignored.
Yeah, I've always been against that type of crap.
It's why Ubuntu, even Debian, and especially RedHat were never really viable distros for me when things like Slackware, Alpine and Void exist.
I don't need a ton of abstraction between me and what I'm trying to accomplish.
I think that's the crypto policy configuration which was required for some government certification iirc. It's been a while but I ran into this too.
There was a document on access.redhat.com that talked about it.
> or use a different distro
For example, Qubes OS: https://qubes-os.org
By default, packages you install from the OS have SELinux labels set for correct operation, and sometimes have booleans you need to enable to allow more advanced use. Anything you install yourself (e.g. tarballs) are completely unrestricted. It sounds like you need to get a better understanding of where the lines are.
When I used Fedora for desktop, VS Code triggered warnings because of a SELinux configuration. Something about using writable memory as executable.
The discussion on the topic was disappointing. Chrome does this, all Electron apps do this, VS Code does it. It was insisted that the warnings were fine because this is insecure and the developers should just fix their applications.
I do not have the patience to waste two hours researching every single complicated solution that every single application uses to make things work just to personally decide whether it's safe enough to whitelist it.
Long story short I'm using Mint now.
All of that, because of some warnings? And now you're happy because you don't see the warnings so you have the false sensation of security
Pointless warning spam drowns out real issues in the logs all the time. You cannot expect an end user to fix chromium based applications or stop using them, so all you end up doing is making the system less usable and less secure.
There are two components to SELinux alerting mechanisms, both of which are documented.
For GUI notifications open the sealert app and disable alerts. For journal/syslog reports disable the setroubleshoot daemon dispatch plugin for auditd:
You can also uninstall the setroublshoot-server package completely, and all AVC denials will continue be reported separately outside of the journal.Sure, but even disabling SE Linux all together seems like a lighter and more sensible solution to me than changing distros. I doubt those applications are suddenly going to stop doing the things deemed insecure because they're running on a different distro, so even just allowing those actions seems far easier and still better off than changing distros. I generally try to fix all SE Linux issues as they come up, but when I just need something working and don't have time to muck with it, I've disabled it in the past. Yes, I know it makes Dan cry, but having people screaming for something that they need immediately to do their jobs makes me cry.
No, I actually tolerated it for a long time before switching. What made me switch was that Fedora became so horrendously slow that it took 15 minutes just to open a web browser. I even tried launching things with syscall tracing but the output just literally froze mid-line all the time while the system was writing to disk. Even though my RAM was mostly unused, it just kept freezing all the time.
This is a problem in ALL linuxes as far as I know. When Linux gets IO-bound, literally everything gets stuck and it's insane. My mouse cursor position doesn't depend on my hard disk. I have a dozen cores. I don't understand. I thought this kind of issue was solvable on a single core with just a round robin scheduler. How come things still get stuck?
It could be that the problem was that I installed every DE I could find to test them, but even after uninstalling a lot of things, the system never recovered its original speed.
I installed Linux Mint on the same hard disk and things run smoothly. In particular, I love how Cinnamon actually keeps the list of applications in memory instead of starting a search every type I open the start menu. The DE has its shortcomings but it's pretty decent otherwise so for now I'm happy with it.
P.S.: also when I tried to use git with apache, checking out overwrote my SELinux types and contexts, which meant I had to figure out AGAIN how do configure all this stuff just so I could access a wordpress site in localhost that was saved in my home folder. For a while I just gave up using branches in git. Now I just use Mint.
This is the modern world we live in. Decisions like this drive life.
I’ve had that POS SELinux block me from logging directly into the console with root (nothing wrong with the pwd). Thank VMware for snapshots. I hate SELinux. But the job requires it. As for people who seem to love it so much, they probably don’t have to deal with it all the time.
> As for people who seem to love it so much, they probably don’t have to deal with it all the time.
Or they put in the time to learn it so they don't get frustrated when they get blocked by something, because they know how to resolve it.
I wish I had the hours to dedicate to every single technology I'm using, but alas...
This is one of those technologies that people shouldn't be using if they didn't take the time to learn it.
It's not like say, nginx or a linux distro, where you don't need to know the ins and outs to get it up and running.
The problem is that when people don't know how to use it and instead turn it off they're immediately deluged from every side with pathetic nerds screaming that YOU DONT HAVE TO TURN IT OFF ANYMORE RUN THIS ARCANE SEQUENCE OF COMMADS THAT YOU DONT UNDERSTAND AS ROOT AND THAT WILL FIX THE ONE ISSUE YOU HAVE without understanding that not every computer system needs to be locked as tight as a server that's being shared with a bunch of untrusted users who are running god knows what.
We can’t ask every car driver to be a mechanic. Specialization is born of finite time and is valuable.
“Just learn to use it bro” constantly breaks Yeah ok.
Followed by "surely the year of the Linux desktop is at hand!"
I'm not going to link it here given his disdain for this site but jwz at least got the CADT development right. If you stop fucking rewriting things every couple of years then maybe the average user could catch their breath and catch up but if you keep changing things that don't need changing (ALSA -> PulseAudio -> pipewire -> whatever is already in the works to replace pipewire) instead of ACTUALLY FIXING THEM then you lose the right to be surprised when someone just trying to use their computer just gives up.
The amount of times I've seen setenforce 1 is ridiculous, but not suprised.
GRSec is better imho but I’ve never convinced anybody to put it in prod so meh
I've never used Grsecurity but I seem to remember that the devs didn't play too well with mainline kernel devs.[0]
[0] https://lwn.net/Articles/721848/