SELinux, Seccomp, Falco, and You: A Technical Discussion
sysdig.comI fought for years against the culture of just turning off SELinux. I read every doc trying to Do The Right Thing when configuring the likes of vsftpd, samba or kvm.
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.
I've never been a fan of SELinux, in the context of what a "normal" GNU/Linux install looks like.
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.
t's trying to contain software which wasn't written to a strict boundary, to a strict boundary.
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.
Its worse.
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.
My experiences differ greatly from yours.
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".
My experience with Red Hat (or CentOS) is that the default SELinux policies usually work out of the box, so turning it off grants no benefit.
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.
I envy you. Really. I tried to be that guy who got selinux right. I couldn't.
For years I were that guy who told it's friends they are morons for turning it off.
I other words you have never deviated from the distro-provided script. In other words, the distro provider owns the server.
Sure I have. There are some things that are done in a "non-standard" way because it works better for us.
Instead of just turning off SELinux, however, I did things "the right way" (fixing labels, contexts, etc.).
I think the main problem is that it's too much of a pain. Seems like whenever I configure DHCP, Bind, Postfix, Mysql, or other popular daemons, as soon as I get into a non-trivial configuration I start getting SElinux complaints.
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.
I've worked with SELinux professionally since 2002. The whole point of mandatory access controls is to NOT take the config file as gospel: rather, there are security goals we want to achieve even in the face of compromised daemons, or compromised app admins.
That means we do have to write some of these things down twice, because we want to have a fence and a lawn.
Well in my experience the fence and lawn are so often based on different information that it's useless. Thus the common case is to turn off SELinux.
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.
I think the main problem is that it's too much of a pain. Seems like whenever I configure DHCP, Bind, Postfix, Mysql, or other popular daemons, as soon as I get into a non-trivial configuration I start getting SElinux complaints.
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.
> 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.
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"
Thanks for pointing this out! I used SELinux with RHEL5 and somehow missed this when I retried SELinux recently. I will definitely play with it again soon...
> You can't run a specific program as unconfined, generate a policy from the errors, and enable it after a while.
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...
It's too hard. The fact that there was a culture of disabling it means that it was a total failure as a tool to secure the average server.
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.
Doesn't Android use SELinux in some shape/form now?
Yes. I posted an interesting technical article I found about it on here recently: https://ge0n0sis.github.io/posts/2015/12/exploring-androids-...
[Edit] this is specifically about the SELinux Kernel policy in Android
Android can get away with it, as it basically is what SELinux was made for. A device in "hostile territory" where even the user can be the "attacker".
I gave up very early on after I ran up against dontaudit rules.
The selinux "problem" has parallels to the recent discussion of pgp.
Visibility is good, but I have found SELinux to be rather simple. Most applications can be automatically configured and supported by Ansible with SELinux enabled. Most community chef cookbooks also support SELinux to some degree (depending on how much you customize things). The default policy is "Targeted" which only protects Redhat supported applications by default. They even added the concept of unconfined users and types which makes management of the systems even easier. It's when folks try to overlay their custom apps into Redhat space that they get stuck. Overlaying your apps can be done, but you have to add the appropriate labels via semanage to the system. You can even add these custom rules in your custom rpm's.
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 like it when security polices are compiled into the program and like it even better when they are impossible to disable. That way programs avoid getting out of sync with best security practices since they will start crashing for all users/developers. Not just users of X but not Y. However programs that try to work with pledge/capsicum/seccomp/others are great but always going to be in a very small minority. So something like SELinux and Apparmor being able to enforce policies on arbitrary software seems like a necessary seatbelt.
I used SELinux commercially in 2000 on an embedded surveillance platform project. I've never used it since, because it's such a hassle to deal with. Special snowflake systems are just so rarely the right thing to do.
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.