Hacker News Reader

Comment by daurnimator | Hacker News Reader

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.

View on HN

If you don't understand how SELinux works why do you have access to a production environment that utilizes it?

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.

Is this a daemon from a standard rpm or some other? Because others typically run unconfined and so shouldn't be a problem.

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.

Any good developer should be able to have a good grasp of basic sysadmin activities.

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

We sysadmins don't exactly love it, either...

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.

Reply on news.ycombinator.com