6 ms·

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

by simias 10y ago

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.

lima 10y ago
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
- simias 10y ago
  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.
  - lima 10y ago
    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.
    - clarry 10y ago
      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.
      - lima 10y ago
        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.
- tomaac 10y ago
  This is non-persistent and after reboot this seboolean will be set back to 0. You must use -P flag to make it persistent.
  - lima 10y ago
    You right, of course. Thanks for noting it! Too late to edit.
user5994461 10y ago
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 ;)
- testUser69 10y ago
  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.
  - justaman 10y ago
    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.
    - bonzini 10y ago
      There is an SELinux boolean which is pretty much "I use Mediawiki".
  - joseph 10y ago
    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.
    - jeffgus 10y ago
      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.
sh_tinh_hair 10y ago
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.
- e12e 10y ago
  Nit; a (Linux) chroot is not a jail. A bsd jail is more like an lxc container.
  - sh_tinh_hair 10y ago
    Understood. Same privilege escalation applies. ..and the syscall chroot is used between systems as a primitive in either os space and semantic.
  - Drdrdrq 10y ago
    Except AFAIK jail is meant to be secure while lxc (or at least docker) containers are not. Right?
    - e12e 10y ago
      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.
      - jeffgus 10y ago
        Yeah, docker, initially, didn't use SELinux, but that was before RedHat took interest. RedHat likes making things more secure with SELinux.
VT_Drew 10y ago
>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.

by simias 10y ago

lima 10y ago

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

simias 10y ago
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.
- lima 10y ago
  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.
  - clarry 10y ago
    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.
    - lima 10y ago
      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.
tomaac 10y ago
This is non-persistent and after reboot this seboolean will be set back to 0. You must use -P flag to make it persistent.
- lima 10y ago
  You right, of course. Thanks for noting it! Too late to edit.

user5994461 10y ago

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 ;)

testUser69 10y ago
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.
- justaman 10y ago
  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.
  - bonzini 10y ago
    There is an SELinux boolean which is pretty much "I use Mediawiki".
- joseph 10y ago
  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.
  - jeffgus 10y ago
    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.

sh_tinh_hair 10y ago

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.

e12e 10y ago
Nit; a (Linux) chroot is not a jail. A bsd jail is more like an lxc container.
- sh_tinh_hair 10y ago
  Understood. Same privilege escalation applies. ..and the syscall chroot is used between systems as a primitive in either os space and semantic.
- Drdrdrq 10y ago
  Except AFAIK jail is meant to be secure while lxc (or at least docker) containers are not. Right?
  - e12e 10y ago
    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.
    - jeffgus 10y ago
      Yeah, docker, initially, didn't use SELinux, but that was before RedHat took interest. RedHat likes making things more secure with SELinux.

VT_Drew 10y ago

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