[mmh0000]

Hiding from SELinux is clever, but SELinux (for most users not running MLS) is a final level of defense. If you get to the point where SELinux is saving your butt, you've got problems higher up in the stack.

For me, the real scary part is the hiding "Audit Evasion" (for those not in the know, here's a link https://www.redhat.com/en/blog/configure-linux-auditing-audi...);

Audit is supposed to be able to track anything and everything that happens on a Linux box. Every login, application, socket, syscall, all of it. The fact that they can bypass it is HUGE. You're not supposed to be able to disable auditd without rebooting the system (when correctly configured). And rebooting the system should* trigger other alarms for the security team.

[kpcyrd]

The rootkit runs in ring0, at that point all kernel-enforced security controls are potentially compromised. Instead, you need to prevent the kernel module from being loaded in the first place. There are multiple ways to ensure no further kernel modules can be loaded without rebooting the computer, e.g. by having pid=1 drop CAP_SYS_MODULE out of it's bounding set before starting any child processes. After it has been loaded it's too late to do anything about the integrity of your system.

[hugo1789]

That is a critical observation. Last time I had to root an Android device it hat pretty robust defenses like dm-verity and strict SELinux policies (correctly configured) and then everything collapsed because the system loaded a exfat kernel module from an unverified filesystem.

Permitting user-loaded kernel modules effectively invalidates all other security measures.

[iberator]

Naive question: does Linux check checksum of loaded modules? If not I could just replace them and voila?

[fc417fc802]

What would it be checking against? There's no central signing authority the way there is with Windows. (I mean I guess a distro could implement that but then how would I load my own custom modules?)

The kernel provides the option to embed a signing key for kernel modules at compile time. But (AFAIK) you'll need to compile your own kernel to go that route.

[stackghost]

I'm quite surprised to learn that Android allows this

[surajrmal]

It doesn't.

[finagler]

> SELinux (for most users not running MLS) is a final level of defense

if so, why is it there at all?

Years back when our team was dealing with weird permission issues on multiple levels due to SELinux, I found little value in it.

[arcfour]

I don't mean this to come off as rude, but how much did you know about SELinux?

Because in my experience, when people are "dealing with weird...issues" and "[finding] little value in it" they usually don't understand what it is and how to use it.

This makes any tool difficult to appreciate.

[mmh0000]

Don't misunderstand my original post. SELinux is AMAZING. But, if SELinux in the default "targeted" policy is the thing that's protecting you, that's good, but it means there are some major bugs or misconfiguration higher up (i.e., in your web server).

I assume you know what a network firewall is. Think of SELinux like a "System Call Firewall". SELinux will protect you from many so-called "zero-day" vulnerabilities. It watches every syscall an application makes, looks at its policy, and decides if that syscall should be allowed/denied. It is a good thing.

However, SELinux is really not user-friendly, though it is extremely well documented and learnable. (run `man -k selinux` to see all the man pages) Red Hat also has thorough documentation (https://docs.redhat.com/en/documentation/red_hat_enterprise_...)

Specifically, to your "weird permission issues". That is a "problem" with SELinux; it doesn't surface errors well. The TL;DR is: if you get a "permission denied" error, and you rule out the obvious (i.e., filesystem permissions), then you need to know to blame SELinux and look at the `/var/log/audit/audit.log` file.

That file is technically human readable, but there are tools that make it much easier, such as `ausearch` and `sealert -a`.

---

https://danwalsh.livejournal.com/71122.html

"Now this is a horrible exploit but as you can see SELinux would probably have protected a lot/most of your valuable data on your machine. It would buy you time for you to patch your system."

[bitfilped]

...as a last line of defense. MAC is also a stronger system than DAC to being with, so a lot of places may opt to have it in place anyway for inexperienced/careless/lazy admin mistakes. Sorry you struggled with writing SEL policies, but it's a very valuable tool when you run systems that are exposed to the internet or other hostile environments.