SELinux, Seccomp, Falco, and You: A Technical Discussion
sysdig.com
sysdig.com
Didn't manage to keep them working jerks-free long enough without disabling it. Daemons always find a way to break with selinux on with me.
After years, I just gave up. I feel sad about it, but just after install, I SELINUX=disabled them.
Is Selinux too hard? Or am I too incompetent? I really don't know.
[Edit] this is specifically about the SELinux Kernel policy in Android
I think it's found its niche, finally, on Android because you can't really break an Android phone the way you can a linux server. You don't have root, the system doesn't change much, certainly not at the linux layer.
Sure I can track them down and fix them, but there's only so much I'm willing to do. Seems like what SELinux should do is read the same config file the daemon does. That way when a distro makes changes to the filesystem layout that SElinux gets a free ride.
After all on a well run system there should be exactly one place for any single piece of important information, not two.
That means we do have to write some of these things down twice, because we want to have a fence and a lawn.
If you need the same info updated in two places you are doing it wrong. It could be moved up a level with a configuration management system. That way you could say Daemon X log in directory Y, and both places would get updated.
This is expected, otherwise the policy would be 'permit everything'. To me, it seems the problem is a combination is:
- To complex configuration, with policy compilers, etc.
- The use of file labeling to control access to file objects.
- SELinux as a whole is binary: either it is on or off. You can't run a specific program as unconfined, generate a policy from the errors, and enable it after a while.
AppArmor might be slightly weaker, but its profiles are much easier to write, file permissions are part of the configuration policy, and you can run specific programs in warnings-only mode for a while and generate a policy from the access violations.
SELinux always left me frustrated. AppArmor has mostly been a walk in the park.
You can make individual domains permissive with the overall system in enforcing. It's available in RHEL6 and RHEL7, I'm not sure about RHEL5.
"semanage permissive -a httpd_t"
You absolutely can. SELinux reports errors to the audit log, then you can run audit2allow(1) to find out why the error occurred and how to fix it. See, e.g., https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
I've only just managed to put into words what my misgivings are after reading this article: it feels like anti-virus software. The trouble is, it's bolted-on security. It's trying to contain software which wasn't written to a strict boundary, to a strict boundary. So you start with a crappy boundary of existing insecure software. That doesn't really achieve much - it prevents expansion of each process' role, but it's already a huge boundary most have.
It makes more sense in the context of "fresh" Linux OS software, e.g Android, but that's exactly where a strict policy from the start, like seccomp, would have done the job.
I think the article misses that there's a third way: subdivided software written with strict roles and boundaries in the first place. Hence why I classify this as "anti-virus" - its enforcement only kicks in after compromise. Prevention is better.
Exactly. That's why NSA, decades ago, wrote SELinux. It wasn't intended to be a security measure. It was intended to encourage development of user-space software which lived within strict security limits.
That never happened. The desire for loopholes ("must phone home", etc.) beat security restrictions. All a single-player game really needs is read access to its own assets, input from user input devices, output to graphics hardware and sound, and the ability to write in its own preferences/save directory. Try to find a commercial game which will run under such restrictions.
SELinux basically implements the concept of "trusted computing". This is a military term, and its about how the generals in pentagon can trust a computer in the field to not "leak" sensitive data (like how mismanaged the war is). This be it to the enemy or ones own soldiers.
Later big media would embrace the term as an alternative to DRM.
Effectively SELinux treats anything and anyone as a potential attacker, including the owner and user on the computer it is installed on.
And the reason it "makes sense" on Android is that the owner of the device is not the owner of the OS, that is the OEM, carrier and ultimately Google.
I've got a few dozen Linux servers of various roles (authoritative DNS, database, mail, web, etc.) publicly facing and I run SELinux on all of them from the moment they are installed (literally, it's enabled and enforced in my kickstart files).
I honestly can't recall a single issue in the last five years or so, at least, where the "fix" was "disable SELinux".
The few times SELinux has "broken" something the fix usually been as simple as creating an fcontext equivalence (if you want to install things in a custom path), enabling a SELinux boolean, or maybe a simple custom policy module granting some additional permissions. None of that is particularly difficult.
If you really want to lock down your custom software with SELinux or go beyond what the default Linux access controls grant you, that is definitely more work, but I've never felt that SELinux is enough of a maintenance burden that I should turn it off.
For years I were that guy who told it's friends they are morons for turning it off.
Instead of just turning off SELinux, however, I did things "the right way" (fixing labels, contexts, etc.).
The selinux "problem" has parallels to the recent discussion of pgp.
If you want to see the original complexity of SELinux, use the MLS policies, remove the unconfined users and types. That is the SELinux that the NSA wrote that folks mentioned here. Dan W. at Redhat made it significantly easier. Now you can even pass the soft errors from Permissive mode into tools like audit2why or audit2allow that will suggest Boolean you can enable, or rules you might create. He also adapted it to support systemd and containers to a degree.
I do believe this type of approach will become easier as CI/CD becomes the norm, but that's gonna be awhile yet.
IMHO to date you will often get more value for time invested out of alternate strategies like thinning down a kernel and userspace, running a server diskless with frequent reboots, adding a second server for failover, using a grsec kernel, or running a decently maintained and tuned IDS/firewall combo.