I am (was - new job now) guilty of disabling selinux on the fleet of servers managed by puppet. I was hoping that the modules listed in the article would show that configuring selinux is actually easy, but I came away with my opinions unchanged. selinux requires a fair amount of investment to deeply learn how it works and what the requirements are for a bunch of apps. As a developer casually working with the ops team to automate their configuration, I didn't have the time or inclination to undertake that learning for what I perceived to be only marginal improvements to our systems.
For what it's worth, that system had about 60 different applications we were running that were provided by a vendor, and their official recommendation was to disable selinux. They never provided (afaik) configurations or guidance to run their apps under selinux.
I'm guilty of the same, and in fact our corporate AMI has selinux disabled. Not my choice, though I'm at least complicit in that I've not protested. Vendor supported apps are the biggest issue. If we have any issues, selinux is the culprit until it's disabled. Even, after ruling it out, you can forget about vendor supported RCA if you turn selinux back on.
One compromise to consider is using the unconfined domain (unconfined_t) to offer a more flexible arrangement. Of course this won't help you in a compliance situation (like PCI/RMF/NIST) but it's worth considering.
I don't turn on SELinux, as it invariably gets in the way.
It adds a whole extra step between coding a feature and deploying it. e.g. if I want to add a feature to an existing daemon to cache things in /var/cache/foo, then before deploying, I'll need to make sure the relevant SELinux policies are updated.
Also, I find SELinux gets in the way when debugging a live server. Often to solve a complex issue I'll need to ssh into a production server and inspect some sort of state or produce dumps; but if that machine has selinux installed, I end up running into it at some point or another.
I feel like there is a huge upcoming market for well designed developer-centric tools that allow developers to use stuff like SELinux without also becoming a sysadmin. SELinux feels like a tool only a system admin could love. Puppet (or Chef, Ansible etc) feel like only a tool a release automation engineer could love.
Startups and small companies rarely spend enough on operations and I feel as if there is bit of a death by a thousand paper cuts across the board for productivity and security due to tools written for sysadmins, and "devops" engineers.
> Puppet (or Chef, Ansible etc) feel like only a tool a release automation engineer could love.
The devil is in the details. Things like logs, packaging, and email sound dead easy, but they get complex fast. Trivial implementations ('just on my own workstation') are always dead easy, but making actual environments that scale sensibly is difficult and rapidly run into all sorts of edge cases.
Configuration management tools are complex because configuration management is complex. You can always move with the herd and go Docker instead... but now instead of managing the configuration management tool... you're managing Docker, which is just as much overhead and has more edge cases you need to cater to.
If you want simple tools, then constrain yourself and run in a managed environment (eg AWS's Beanstalk). As soon as you want environmental flexibility, you open a can of worms that can only be dealt with using a complex tool.
The feeling you describe here is part of what led to the design of Sysdig Falco (http://www.sysdig.org/falco). While certainly not a 1:1 SELinux replacement, our goal was to use a much simpler, understandable model for describing & monitoring security policies for linux hosts.
1. Because I'm often the domain specialist in how a certain daemon works and I've been asked to debug some issue
2. Because the production environment didn't have SELinux, until the ops team that manages it read this blog article, and decided to enable it: but I still need to do my job.
14 comments
[ 4.2 ms ] story [ 178 ms ] threadFor what it's worth, that system had about 60 different applications we were running that were provided by a vendor, and their official recommendation was to disable selinux. They never provided (afaik) configurations or guidance to run their apps under selinux.
https://wiki.gentoo.org/wiki/SELinux/Tutorials/What_is_this_...
It adds a whole extra step between coding a feature and deploying it. e.g. if I want to add a feature to an existing daemon to cache things in /var/cache/foo, then before deploying, I'll need to make sure the relevant SELinux policies are updated.
Also, I find SELinux gets in the way when debugging a live server. Often to solve a complex issue I'll need to ssh into a production server and inspect some sort of state or produce dumps; but if that machine has selinux installed, I end up running into it at some point or another.
Startups and small companies rarely spend enough on operations and I feel as if there is bit of a death by a thousand paper cuts across the board for productivity and security due to tools written for sysadmins, and "devops" engineers.
The devil is in the details. Things like logs, packaging, and email sound dead easy, but they get complex fast. Trivial implementations ('just on my own workstation') are always dead easy, but making actual environments that scale sensibly is difficult and rapidly run into all sorts of edge cases.
Configuration management tools are complex because configuration management is complex. You can always move with the herd and go Docker instead... but now instead of managing the configuration management tool... you're managing Docker, which is just as much overhead and has more edge cases you need to cater to.
If you want simple tools, then constrain yourself and run in a managed environment (eg AWS's Beanstalk). As soon as you want environmental flexibility, you open a can of worms that can only be dealt with using a complex tool.
2. Because the production environment didn't have SELinux, until the ops team that manages it read this blog article, and decided to enable it: but I still need to do my job.