Dan Walsh, a Red Hat security engineer, writes about SELinux: how it contains exploits, sandboxing, and labeling.
HN commenters cite his sandbox posts for running Firefox in an SELinux sandbox, and note SELinux policy-writing tools still need work.
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_linux/7/html-single/selinux_users_and_administrators_guide/index)
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…
> Well that's nonsense. SELinux can protect against anything AppArmor can since AppArmor provides only a subset of features.
This is from Dan Walsh who is quite famous in the SELinux community [1]. See the part "Why didn't SELinux block it?"
Sure you can configure SELinux with a stricter policy, but virtually nobody does that in practice, they use the defaults, mostly because SELinux policies are really only used to fix stuff SELinux default policies break, usually using the audit2allow or whatever its called.
> I sense you might not be interested in this since you've said you just want benchmarks
If the EDR/antivirus industry can have various test suites and testing organisations, the same methodologies can apply to OS security subsystems. Let's see what happens with your default RH/SELinux, Ubuntu/Debian & AppArmor, and for shits and giggles OpenBSD, and see how they fare against exploits and vulnerabilities harvested over the years, and make reproducible labs. That's what I'm asking; I'm not going to scour security advisories to do tit for tat comparisons, I would rather see a well thought approach to this.
We do this kind of comprehensive benchmarking with all sorts of software such as compression, cryptographic libraries, compilers / languages, etc. Traditionally this would've been harder in the days when virtualisation and utility computing was nascent, but the infrastructure part is pretty achievable these days. Just need to someone to expend the effort (and I'm…
> Still don't care about the feature set, show me a useful benchmark.
"I don't care to understand the differences in security thees systems provide"
That's what you're saying here. Which means you're not going to be evaluating these systems in any way that matters.
> If SELinux prevents a hypothetical that's great, but security is a tradeoff and I'd opt for convenience and simplicity to sacrifice potentially negligible risk.
You're asking for benchmarks, but already here your willing to dismiss the results because you don't really care about them, you care about "convenience and simplicity" and security being good enough, right?
In that case, sure AppArmor is good enough for most people.
But so is a flimsy chain look. If you want to actually secure something and not just deter, you'd want a deadbolt and sturdy door, right?
The point is, the feature sets matter, precisely because so many attacks are hypothetical. You have to see and speculate what attackers might do and have things in place to prevent that. SELinux facilitates that a lot more than AppArmor does.
That's the fundamental point here, and not something you will likely find a nice graph to support. If you ask an AI to generate one for you it might be able to though. If you really still think you need it.
> For example, I'm seeing that SELinux didn't mitigate ShellShock where AppArmor did (despite being an attack vector that isn't really common).
Well that's nonsense. SELinux can protect against anything…
Unfortunately, this is an area that could use some work. Tools for writing new policies are a long way away from what they could/should be. If you need something to work with SELinux that doesn't come with a policy you have essentially three options, in order of preference:
1) Develop a new policy from scratch. This is fairly hard, and the tools, such as they are[0], are not great. There's a couple of good resources out there, including [1] which has some good examples, and Dan Walsh's blog [2].
2) Use audit2allow to generate a policy semi-automatically. The resultant policy won't be very clean, and will almost certainly be more permissive than it needs to be, but if 1) is too much work (and I wouldn't blame you for this), then this is the next best thing.
3) Run your binary in the unconfined domain (do something like chcon -t unconfined_exec_t /usr/local/bin/foo), but leave the rest of the system enforcing. This will mean your binary itself is able to do anything, but the rest of the system is still protected.
Oh, and if you haven't read it before, you should definitely check out [3](pdf).
0: http://oss.tresys.com/archive/slide.php
1: https://github.com/TresysTechnology/refpolicy/blob/master/policy/modules/system/application.if
2: http://danwalsh.livejournal.com/
3: https://people.redhat.com/duffy/selinux/selinux-coloring-book_A4-Stapled.pdf
Funny, I've been running it on my laptop since Fedora 18 (current on 24 Beta). I might notice it maybe once every few months when a script or some software I'm futzing with tries to do something out of the ordinary:
[jeff@omniscience ~]$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 30
And yes, my nick is a throwback to Security Enhanced Linux, but when the next exploit for some common library or software comes out and I'm not affected due to SELinux, I'll smile. Can you say the same?
A few quick examples I pulled up:
https://blog.namei.org/2008/01/08/selinux-mitigates-remote-root-vulnerability-in-openpegasus/
http://danwalsh.livejournal.com/10131.html
https://www.reddit.com/r/linux/comments/1xdokz/selinux_saved_our_asses_xpost_rselinux/
It could be difficult. My first thought would be a SELinux policy like this article attempted:
https://danwalsh.livejournal.com/28545.html
One might have different profiles with different permissions. A network service usually wouldn't need your hone directory while a personal utility might not need networking.
Also, that concept could be mixed with subprocess-style sandboxing. The two processes, main and sandboxed, might have different policies. The sandboxed one can only talk to main process over a specific channel. Nothing else. People usually also meter their CPU, RAM, etc.
INTEGRITY RTOS had language-specific runtimes, esp Ada and Java, that ran directly on the microkernel. A POSIX app or Linux VM could run side by side with it. Then, some middleware for inter-process communication let them talk to each other.