SELinux bypasses(klecko.github.io)
klecko.github.io
SELinux bypasses
https://klecko.github.io/posts/selinux-bypasses/
56 comments
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.
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.
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
> 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
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.
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.
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...
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
.. 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.
Implementation of SMI transfer monitor (STM) support for Coreboot.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!
Me too, having dealt with those people many years ago.
Amusingly, a big problem during the Cold War era was administrative. NSA's main HQ was at Fort Meade. When that filled up, various auxiliary functions, such as personnel and training, were moved out to Friendship Annex (FANX), near what was then called Friendship Air Terminal, now "Baltimore-Washington International". Working at FANX had less prestige than working at Ft. Meade. Computer security was at FANX. This had a real effect on the effort. Being at FANX meant being on the second team.
NSA had a major downsizing after the collapse of the Soviet Union, and a major rework for the War on Terror. I can't speak to the modern situation. But computer security is still at FANX.
Amusingly, a big problem during the Cold War era was administrative. NSA's main HQ was at Fort Meade. When that filled up, various auxiliary functions, such as personnel and training, were moved out to Friendship Annex (FANX), near what was then called Friendship Air Terminal, now "Baltimore-Washington International". Working at FANX had less prestige than working at Ft. Meade. Computer security was at FANX. This had a real effect on the effort. Being at FANX meant being on the second team.
NSA had a major downsizing after the collapse of the Soviet Union, and a major rework for the War on Terror. I can't speak to the modern situation. But computer security is still at FANX.
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.
Are you familiar with techniques such as mseal? People are trying to take measures to make things in their namespace or address space immutable to protect against partial compromises. It's actually more useful than it seems however it would seem that vendors who are trying to protect selinux this way are not actually able to do it in a robust manner.
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.
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
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 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.
FWIW using linux-zen made those hang-on-IO problems quite a bit more tolerable, but yeah, that problem is ancient...
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:
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
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.
This is the modern world we live in. Decisions like this drive life.
The actual difference between Discretionary and Mandatory Access Control: in DAC, a user who owns a file can decide who has access to it (by their discretion). In MAC, the security policy comes from above (by a mandate). A MAC system can have a policy saying that users in the engineering group can't read files created by the accounting group, and there's nothing the users involved can do about it (besides trying to relay through someone they can both communicate with). In DAC the accountant could add the engineer to the file permissions if they want to.
Users are fundamentally trusted in DAC and untrusted in MAC. Microsoft's implementation of MAC even provides a facility to log operations that are denied by policy, so the user who attempts to violate the policy can be punished. Additionally, it doesn't allow users to see the policy (unless explicitly granted that permission).
Users are fundamentally trusted in DAC and untrusted in MAC. Microsoft's implementation of MAC even provides a facility to log operations that are denied by policy, so the user who attempts to violate the policy can be punished. Additionally, it doesn't allow users to see the policy (unless explicitly granted that permission).
The article mentions hypervisors used by Samsung and Huawei Android phones which enforce read-only access to certain memory regions of the Linux kernel. Exists such a hypervisor as FOSS project?
EDIT: a quick search found that Linux' KVM could potentially be used: https://lpc.events/event/17/contributions/1486/attachments/1...
EDIT: a quick search found that Linux' KVM could potentially be used: https://lpc.events/event/17/contributions/1486/attachments/1...
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?
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.
> or use a different distro
For example, Qubes OS: https://qubes-os.org
For example, Qubes OS: https://qubes-os.org
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.
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.
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.
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.
There was a document on access.redhat.com that talked about it.
> 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.
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.
Where does the kwrite() come from? How do you get the privileges to write to arbitrary memory addresses?
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.
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.
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.
Why use RHEL if you don't want one of the main advantages it offers? There have been numerous exploits that RHEL has been protected against because of SELinux and their policies.
Sure, not all servers need to be secured, but why use RHEL then? Why not use Debian or some RH fork that doesn't have it on by default, or even SuSE?
The people who disable it out of convenience are generally bad admins, and generally being lazy and/or incompetent.
Sure, not all servers need to be secured, but why use RHEL then? Why not use Debian or some RH fork that doesn't have it on by default, or even SuSE?
The people who disable it out of convenience are generally bad admins, and generally being lazy and/or incompetent.
Thank goodness you're here to tell them that. It would really be a shame if they did threat modeling and determined it was not necessary for their use case. That would make you look goofy and kind of a jerk.
Heh. Yeah, people mostly disable SELinux because they did threat modeling and determined it made sense, and don't just switch it off due to laziness or incompetence.
I think claiming that is a pretty goofy argument, personally.
I think claiming that is a pretty goofy argument, personally.
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.
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.
> 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
This is possibly the dumbest thing I read in a while...
1. PipeWire was written to fix PulseAudio and is a drop in upgrade. How do you think things get fixed otherwise? 2. Why would anyone rewrite PipeWire at the moment, why would you think that?
This is possibly the dumbest thing I read in a while...
1. PipeWire was written to fix PulseAudio and is a drop in upgrade. How do you think things get fixed otherwise? 2. Why would anyone rewrite PipeWire at the moment, why would you think that?
1. By fixing ALSA or PulseAudio instead of writing pipewire
2. Because writing something new is easier than trying to understand something already written. Maintenance is not sexy. Writing new things is.
2. Because writing something new is easier than trying to understand something already written. Maintenance is not sexy. Writing new things is.
1. PulseAudio needed a redesign, there was no fixing to be done. It was utterly impossible to support low-latency audio, the protocol was not right, the client API was wrong, the backend was not right etc.. Also, ALSA is the wrong place to add more things, it should just be a driver abstraction.
Also note that PipeWire reuses the most complicated/fundamental part from PulseAudio: the device probing and mixer management. This code took 10 years to tweak and is taken directly from PulseAudio.
As a side note, there was a lot of investigations if things could be written on top of JACK2 but that also was infeasible (mostly the IPC protocol and API needed a rework, no security with memory sharing, support for Video. The scheduling ideas were taken right from jack2, though).
2. This is true but PipeWire is not just a random new rewrite. It was written with a deep understanding of both pulseaudio and JACK (later in the developments) internals and design. Many (of the good) ideas from those projects survived in PipeWire. This is actually a perfect example when a rewrite is a good thing.
Now, what is even easier than writing PipeWire is not understanding why things are done the way they are done and then complaining about it.
Also note that PipeWire reuses the most complicated/fundamental part from PulseAudio: the device probing and mixer management. This code took 10 years to tweak and is taken directly from PulseAudio.
As a side note, there was a lot of investigations if things could be written on top of JACK2 but that also was infeasible (mostly the IPC protocol and API needed a rework, no security with memory sharing, support for Video. The scheduling ideas were taken right from jack2, though).
2. This is true but PipeWire is not just a random new rewrite. It was written with a deep understanding of both pulseaudio and JACK (later in the developments) internals and design. Many (of the good) ideas from those projects survived in PipeWire. This is actually a perfect example when a rewrite is a good thing.
Now, what is even easier than writing PipeWire is not understanding why things are done the way they are done and then complaining about it.
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/
[0] https://lwn.net/Articles/721848/
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.