Hacker News Reader

Comment by simias | Hacker News Reader

The problem with SELinux is that it's disabled by default on many distros. If you follow guides online that weren't written for a SELinux-enabled Linux install then it won't work.

To make matters worse SELinux-related errors can be pretty arcane if you don't know what's going on. I'm usually a FreeBSD guy but I had to setup a CentOS 7 box a little while ago. I thought I was going insane when I couldn't get nginx to connect to a unix domain socket. After a hour of hair pulling and non-conclusive googling I finally understood that it was SELinux related.

I will admit that after that I simply disabled SELinux and never looked back. The benefits didn't seem worth the hassle to me.

If I want additional security and sandboxing I'd sooner use something like FreeBSD/solaris jails. It's not exactly the same thing of course but I find the mental model a lot simpler ("a machine within a machine") than SELinux's complicated and (IMO) hard-to-debug rules.

View on HN

A debugging guide for SELinux, or how to get anything done on a system with SELinux enabled:

1) Configure some software you need.

2) The software doesn't work.

3) Disable SELinux.

4) The software works.

5) F--- SELinux.

After a dozen occurrences of this pattern, your experience will have taught you to begin all deployments from step 5 ;)

What specific software causes problems? I use SELinux on the desktop and have no issues with it other than occasional warnings which don't seem to effect anything. I develop a lot of networked applications and do a lot of stuff with Linux containers.

On the server I usually use Ubuntu and run custom server software running in a container and never have problems.

I had problems with users not being allowed to upload pictures to MediaWiki. It was an internal use only machine so I had no problem with disabling SElinux but I would highly recommend working thru the pain on an internet facing box.

There is an SELinux boolean which is pretty much "I use Mediawiki".

I just ran into one yesterday. I was pulling my hair out because rsyslog wasn't forwarding messages to logstash. I checked and double checked my configurations, tried different settings, and it all looked correct but it still wouldn't work. Finally an strace of rsyslog showed permission denied when attempting to send a message. Aha, SELinux got me again.

Wouldn't it have been easier to check the audit.log? Pump out the contents to audit2allow and you will have a nice new config that would allow your setup. Heck, it would even tell you if there is already a boolean for that config.

I really don't see any reason to disable SELinux. Maybe back in RHEL5 days, but not since then. Just educate yourself on some tools. It really isn't that hard.

Sure, it would have been easier for me to check the audit log, however the idea that it was an issue with SELinux didn't even cross my mind until I used strace. The vast majority of Linux systems I work on do not have it enabled.

You may not see a reason to disable SELinux, but not all Linux systems are RHEL, and don't have it enabled to begin with. I personally would not enable it on a system that did not design for it as a default.

strace is seriously amazing for troubleshooting stuff that you can't just throw some debug print statements into. strace -f -e open -s 4096 -- whatever --foo is my typical usage of it (follow forks, only trace "open" calls (to see what a program might be trying to look for a thing), string size = 4096 so e.g. Paths don't get cut off, -- to say that you're done giving options to strace and all --options should now go to "whatever"). That + ps auxf | less and searching for a process to see how it fits into the tree + lsof -p [pid] + top and hitting c, 1, u (then typing the user of processes I'm interested in) or hitting < or > to change sort columns + netstat -lnp | grep LISTEN....are the basics of how i figure WTF is going on with a system I've just jumped onto. SELinux and systemd with the journal logging sometimes getting in the way of these flows unless you know what you're looking for and are vaguely aware of how they hook into things.

The fix for that would have been:

    setsebool httpd_can_network_connect=1

audit2allow even tells you right away which booleans apply:

    tail /var/log/audit.log | audit2allow

Thank you for that, that might be helpful in the future!

But it kinds of demonstrate my problem with SELinux: when I had my unix socket issue I tried to debug my problem using my usual tools: strace, ls, ps, dmesg, etc... but I couldn't figure out what wasn't working right. All the permissions looked fine and yet I kept getting cryptic failures.

With something like a jail, once it's set up I can just use my un*x admin experience without having to learn a brand new OS-specific (if not distribution-specific) set of tools.

Well, you get that with any security technology and it's just one of many things to be aware of when you use another distribution.

Well, you get that with any security technology

That's just not true. There is plenty of security technology that doesn't require you to figure out new tools. There is security technology that doesn't have tools at all and there is nothing to figure out. The program either works correctly or it's buggy and there is no knob to make a buggy program correct.

And then there is security technology that is more or less understandable with knowledge of existing Unix tools. pledge() on OpenBSD, for instance, doesn't introduce new fancy tools. A program doing something it promised not to do will get killed with abort trap (which can, admittedly, be a little cryptic if you don't know pledge does that). In addition, the name of the binary, the pid, and the offending syscall is printed in dmesg. Perhaps it would be better still if the dmesg line included the word "pledge" as a hint & guarantee that you'd get relevant results on Google.

Well, "security technology" in the context of mandatory access control frameworks. Bad choice of words.

My point is that any ACL framework will require configuration, be it SELinux, AppArmor, Tomoyo, or pledge.

If you want to use pledge to confine applications that don't use the pledge API, it will get complicated, too (admittedly not quite as complicated as SELinux, but still).

SELinux writes denials to the audit log and you get plenty of relevant results.

pledge is obviously much more sane than SELinux, but someone has to write a policy no matter what technology is used.

This is non-persistent and after reboot this seboolean will be set back to 0. You must use -P flag to make it persistent.

You right, of course. Thanks for noting it! Too late to edit.

>I will admit that after that I simply disabled SELinux and never looked back. The benefits didn't seem worth the hassle to me.

YUP, this right here. SELinux needs to be way more user friendly if you want to see wider adoption.

Selinux MAC is painful coming from DAC and it has bitten me numerous times but depending on your environment and exposure it can be a must have.

I wouldn't run an 'exposed' system that had SELinux support (and decent rules) without SELinux. Not discounting chroot, but given root a lot is possible in a jail.

Nit; a (Linux) chroot is not a jail. A bsd jail is more like an lxc container.

Understood. Same privilege escalation applies. ..and the syscall chroot is used between systems as a primitive in either os space and semantic.

Except AFAIK jail is meant to be secure while lxc (or at least docker) containers are not. Right?

Lxc has since 1.0 come with isolation and security as part of it's design and feature set. Docker started as a convenient approach to bundling up chroots - and AFAIK hasn't really made much of a real effort wrt security - other than somewhat ill-advised approach to tacking on (enabling) a feature here or there... (That's not counting external projects like rkt running images as vms etc).

Lxc is much closer to jails in that sense - but eg lxc/Lxd on Ubuntu is hardly (meant to be) a silver bullet.

Yeah, docker, initially, didn't use SELinux, but that was before RedHat took interest. RedHat likes making things more secure with SELinux.

Reply on news.ycombinator.com