
Managing SELinux with Puppet - kiyanwang
https://tag1consulting.com/blog/stop-disabling-selinux-manage-it-with-puppet
======
jsmeaton
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.

~~~
joombaga
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.

~~~
coredog64
After reading the article, I looked up what level of support Amazon offers in
their distribution. Near as I can tell? None.

------
daurnimator
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.

~~~
meddlepal
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.

~~~
vacri
> _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.

