How exactly does SELinux mitigate and prevent Copy Fail and Dirty Frag?
Posted by Old_Management_8966@reddit | linux | View on Reddit | 37 comments
From what I gather, these attacks corrupt the page-cache in memory and leave almost zero traces on the actual disk
I also saw a few people mentioning that SELinux is currently one of the only reliable ways to catch or stop these attacks in the wild. But honestly, I don't fully get why or how it does that
Is SELinux just blocking the specific socket stuff before the exploit even triggers?
Hande-H@reddit
Here's a writeup on it from GrapheneOS: https://discuss.grapheneos.org/d/35110-grapheneos-is-protected-against-copy-fail-and-similar-vulnerabilities-by-selinux
It is AOSP - specific though, your average Linux system won't have this level of integration.
shroddy@reddit
I wish there was a desktop OS with a similar SELinux or AppArmor integration that is still as easy to use as a smartphone.
Barafu@reddit
Ublue family (Bazzite&Co) is getting close. It is surprisingly full of security capabilities.
Vladekk@reddit
But then when something is blocked because of sec. features only llm can diagnose it.
ghost103429@reddit
Not really... The general fix is to set selinux to complain, then run the fixes suggested by journalctl -t setroubleshoot, and turn it back on.
This is pretty much how new selinux profiles are generated. Set the system to complain in order to check what's accessed during normal use, and then use audit2allow -M "application" to generate the correct selinux profile.
Hande-H@reddit
I've been trying out Android 16's desktop mode (beta). It works surprisingly well already and has a lot of potential but it's obviously not quite the same as a PC / desktop OS.
natermer@reddit
SELinux is a kernel feature that is used to enforce "Mandatory Access Control" features. Most of the time Linux uses Unix-style "Discretionary Access Control".
Unix-style stuff is like "read, write, execute" and "owner, group, world" permissions for files. What can and cannot do is determined by resource permissions.
MAC, on the other hand, depends on labels and policies and context. Like you can setup a policy where a user gets a different set of permissions based on whether they logged in locally on a console or over SSH or whatever.
Or you can set it up so that when a program is launched by systemd as a service it is very limited on what it can do in terms of writing and editing files even though it is technically running as 'root'.
Selinux offers very fine grain control over access to different types of system permissions. A common demonstration in the early days of SELinux was to allow people to log in as root on a server over ssh and have no ability to compromise the system. (this turned out to be a bad idea, btw).
This comes with a lot of complexity, though. Also most Linux/Unix programs are designed to handled Unix-style DAC. When they get actions blocked by SELinux they don't know how to handle it. So permissions issues from SELinux rarely "float to the surface".
Like if you try to edit a file by 'vi' and is blocked by Unix write permissions.. it will tell you. But if you try to edit a file and it is blocked by SElinux policy... then it has no idea what happened. It may crash, it may silently fail, it may claim it is a file system permission, etc.
The complexity and alien nature of SELinux causes a lot of usability issues.
So when Linux distributions do ship SELinux they ship the Redhat style "Targeted Policy", which is only really designed to mitigate common software vulnerabilities for servers and workstations. It is designed to be pretty limited in what it does to try to make it as user friendly as possible.
All of this means that SELinux is kinda nerfed out of the box. It only gets used to a fraction of its power most of the time. To fully "lock down" system is huge under taking and while you might see it in special purpose financial, crypto, and military contexts... it isn't something people are going to on their desktops.
In addition to this because SELinux is running as part of the Linux kernel... When the Linux kernel itself has a flaw usually there isn't a whole lot it can do.
Like you can setup a SELinux policy to stop modules from being loaded or block access to different system calls. But those modules get loaded for good reasons and system calls are needed by software.
And if there is a kernel feature that a program is supposed to have access to and it turns out to have a vulnerable bug nothing SELinux can do can automatically fix it.
Yeah sure if there is a bug you can maybe use SELinux to block access to it. But you have to know ahead of time and the right policy change to make and know what software might get broken because of it.
Which really isn't any different then people adding "/bin/false" permissions to /etc/modprobe.d/ for loading certain vulnerable kernel modules.
So take what they are saying with a grain of salt. SELinux isn't a magic bullet here.
Kernel vulnerabilities are kernel vulnerabilities and there isn't a whole lot SELinux can do.
gtrash81@reddit
And most of the time you set it monitoring mode, because stuff must be running 1 week ago and you have never time to create a SELinux policy.
Yes, the helper process exists, but I don't know how many false-positive policies it generated, but it is above 50%.
deleriux0@reddit
As someone who has written SELinux policy in the past and have used it for very specialized usecases like RBAC this is one of the best descriptions I've read online about it.
It's amazing if you can tune it right but an equally huge undertaking.
The technical reason dirtyfrag is blocked in SELinux when I tested it is the exploit cannot open the network socket type to start the attack since it's a particular class of networking not permitted to most confined types.
natermer@reddit
Good, sounds like a win for SELinux then.
I like SElinux in general and I wish more people had it enabled. I also wish Flatpak can be extended to use it and make SELinux be meaningful on the desktop.
Similar to how it is now standard on Android.
deleriux0@reddit
One of the bigger more modern weaknesses is it is not namespace aware.
Would be incredible if you could have separate policies loaded by namespace (whole policies ideally not just a type transition call).
Some sort of CLONE_NEWPOL and some mechanism to offer a new binary policy file after having moved namespace.
I'm the end things have moved on a lot now and the community in general has more readily accepted security isolation through namespaces, ebpf and control groups. Personally I think it's easier to understand but you do lose out as audit logs act as a realtime host based IDS which SELinux made a great use of.
troyunrau@reddit
Sounds like a fun story.
natermer@reddit
don't remember all the details, but SSH is bidirectional. It both sends and receives data.
So what end up happening is that attackers used what little control they had over the SSH shell environment on the SElinux locked down system to start attacking other curious people logging in to that system to check it out.
Panzer1119@reddit
So the issue wasn’t really that they logged in as root, but rather that they all logged in as the same user?
natermer@reddit
Yes. If you are using SSH and log into a malicious system theoretically it can try to use things terminal control sequences into get control of your terminal or trick you into doing something.
Terminal emulators are pretty sophisticated and some terminal controls are exposed through special ansi escape sequences. Things like changing the colors of text in the terminal, or blanking the terminal, or stopping text from being echo'd back to you. This is a big part of how TUIs work to create GUI-like displays using terminal emulators.
So if there is bugs in your terminal then maybe they can be exploited. Or a user might get tricked into typing their sudo password or something like that. It is kinda like how when you log into a malicious website it might be able to trick your browser into doing something or trick you into doing something.
Like I said I don't remember the details and while the environment was very locked down and I doubt if anybody was successfully hacked that way through one of these demo servers, they were certainly trying.
A quick google search turned up this, which goes into some of the issues related to terminal security: https://www.cyberark.com/resources/threat-research-blog/dont-trust-this-title-abusing-terminal-emulators-with-ansi-escape-characters
ready_or_not_3434@reddit
Yeah spot on. We generally just rely on SELinux to limit the blast radius of compromised user-space apps, but if an exploit is corrupting the page cache directly its basically game over anyway.
iOnlyRespondWithAnal@reddit
Great explanation
drdivw@reddit
Great username!
Coaxalis@reddit
ysis was out of username field space possibly :}
Old_Management_8966@reddit (OP)
Awesome explanation, thanks a lot for the detailed breakdown
michaelpaoli@reddit
I seem to recall that AppArmor (think of it as SE light) was sufficient - for at least one or more of these - though I don't recall which one(s).
In any case, SELinux or AppArmor will commonly be used to prevent programs from doing things they ought not be doing - generally blocks 'em on system call or permissions level, and far beyond what basic *nix permissions cover. E.g. I run named, derived from ISC's BIND. AppArmor is configured to it to quite highly restrict what it can actually do with what files/paths, etc. Essentially what it can and ought do is whitelisted. What it has no legitimate reason to do or attempt, it's blocked.
So, SELinux or AppArmor would be blocking, at least for certain exploits and PoC examples, such attacks. That's not a guarantee, though, that it will block all attacks. And merely having SELinux or AppArmor present doesn't suffice, but needs also be appropriately configured.
3dGrabber@reddit
Apparmor has the same errors not floating to the surface problem as SELinux. Spent hours to debug a firefox plugin issue that turned out to being caused by AA selectively blocking filesystem access.
michaelpaoli@reddit
That's really not an issue with SELinux or AppArmor, but rather with the application/program, and such issues go back long before AppArmor and SELinux. Notably programs that don't bother to check the return values on system calls, and go on blindly, or when they do hit exception, error, or something they don't expect, don't bother to issue any kind of diagnostic or the like. Not a new problem, but not the fault of SELinux nor AppArmor. However, if one bothers to check, with SELinux or AppArmor, one can see all that was attempted and denied - so the clues are well there - if one bothers to look. But the responsibility is really on the application/program, to check, and do reasonable things when they hit an obstacle ... and that's generally not remaining entirely silent about it and blindly proceeding - which alas, far too many do. Heck, more than a quarter century ago I was running into such cr*p. E.g. Oracle - they'd released their own web server once upon a time - this was lateish 1990s, probably about 1997 or so. An, well, not exactly trusting Oracle on security - as they tend to f*ck that up ... repeatedly, wanted to run it under a well secured chroot environment. Well, it bombed out .... quite silently. No diagnostics at all. Had to run system call traces on it to see what it was doing and why it was bombing out. Yeah, there were some files it wanted access to ... if that failed ... well, the stupid program didn't even test if the open attempts succeeded or not - it went along blindly as if they had succeeded ... and of course then the program would badly crash. Yeah, that's not the fault of the OS not giving the program access to the file, that's fault of the program failing to do something reasonable when the open attempt failed.
Well, same can be said of Firefox - if it's failing due to lack of access, and doesn't give useful diagnostics as to the issue, that's really the fault of Firefox, not anything else.
mina86ng@reddit
It doesn’t. The only mitigation is to disable the affected modules. Like you’ve observed, the vulnerabilities allow editing arbitrary files which gives practically unlimited permissions to the attacker.
However, as far as I understand, patches and kernel releases fixing both issues already exist.
Jannik2099@reddit
This is incorrect. You can deny the relevant socket calls via LSM hooks (such as used by selinux)
mina86ng@reddit
Fair enough. I’ve mentioned in another comment that my SELinux knowledge may be outdated at this point. With
socket_createhook you should be able to whitelist e.g. only root to use the problematic socket algorithms.Old_Management_8966@reddit (OP)
However, in case of copy fail, SE Linux could prevent access to the AF_ALG socket with a restrictive policy, but it’s a manual process
mina86ng@reddit
Honestly I’m no longer certain of my answer then. It’s been years since I’ve looked deeply into SELinux. If it allows limiting socket types, you probably could create a rule which prohibits AEAD unless it’s run in particular context.
Jannik2099@reddit
First off: selinux is a framework for declaring and enforcing MAC policies. Whether copyfail was prevented depends on the policy used.
SeLinux is a Linux Security Module. LSMs act on system calls via a set of standardized hooks found at https://github.com/torvalds/linux/blob/master/include/linux/lsm_hook_defs.h
At our site, I mitigated these vulnerabilities via eBPF LSM programs, using the hooks socket_create and socket_bind. eBPF is very flexible here as it allows you to introspect the syscall arguments as you need, whereas policy languages like selinux are limited to what the policy can express.
i2295700@reddit
Can you share any details about that implementation?
I thought about using ebpf as well, but have not enough experience to implement that for our environment..
granadesnhorseshoes@reddit
others have written entire dissertations about selinux in response to your question.
A quicker answer is, it doesn't but it COULD. You could setup selinux in a way that prevents regular user access the the vulnerable crypto subsystem. You could have contexts that prevent suid binaries from running outside of specific locations. Neither of these are very common configurations and may even break other things (fixing issues by disabling selinux is a common trope), but they are POSSIBLE with selinux.
Simply unloading the affected modules is a much easier and effective solution.
Old_Management_8966@reddit (OP)
That’s the question, it could, but it is a manual process and I probably don’t yet have the knowledge to set it
anomalous_cowherd@reddit
SELinyx used to come with barely any default configuration at all, so for years it became standard advice to turn it off.
Then OSes and packages started coming with sensible configurations so it was OK to leave it on, and as long as you only used e.g standard ports for web servers then it didn't get in the way at all.
The question with these latest issues is whether the default configuration stops them. My guess is no as SELinux is widespread and on by default now, so there wouldn't have been a need for all the urgent OS patch releases if it did stop them.
Infiniti_151@reddit
It does not. Dirty Frag affected Fedora 44 even though it has SELinux in enforcing mode by default.
skizzerz1@reddit
It’s in targeted mode by default. Users run as unconstrained_u which means they are unimpaired by selinux policy. The OS ships policies for various system services which are constrained and can only do what the policy allows them to.
If you wrote a custom policy for users and constrained them to that policy, then this could have prevented this and similar attacks since the scope of what users are allowed to do may not have allowed the actions required for exploit. This is not an easy feat and takes a lot of time and effort to write said policies.
Infiniti_151@reddit
Targeted is a policy type, not an operational mode.
deviled-tux@reddit
Fedora’s default SELinux context for user accounts is unconfined but for example their Apache server will be confined. I doubt you can reproduce the exploit from a confined domain.