4 ms·

The problem with SELinux is it's very fragile and basically broken outside RedHat distros. As an experiment I installed SELinux on Debian and while I was event

The problem with SELinux is it's very fragile and basically broken outside RedHat distros. As an experiment I installed SELinux on Debian and while I was eventually able to get it stable and working after a lot of trial and error, a disk swap followed by an rsync broke it irreparably. Yes I rescanned the disk or whatever to have SEL relearn/reindex the objects, didn't work. The box was basically unbootable or it would boot and rejected all logins, including root directly to the console, something that should nearly never happen. Documentation is sparse or assumes you have RedHat and it 'just works'. After hours of troubleshooting the only thing that worked was switching it off and saying good riddance.

totony 2y ago
Most distros use https://github.com/SELinuxProject/refpolicy https://github.com/SELinuxProject/refpolicy while RHEL uses https://github.com/fedora-selinux/selinux-policy https://github.com/fedora-selinux/selinux-policy It's also my experience that Fedora has better support for it, but Gentoo used to be good enough with hardened gentoo (they use https://gitweb.gentoo.org/proj/hardened-refpolicy.git/ https://gitweb.gentoo.org/proj/hardened-refpolicy.git/). Redhat and Gentoo are the only ones that officially support it afaik. I think hardened gentoo might have lost popularity since the fall of grsec, but I'm not sure how popular it is currently.
- vlovich123 2y ago
  FWIW Android also uses SELinux & I believe selinux-policy. Have no idea about the quality of the implementation.
  - BSDobelix 2y ago
    >Android also uses SELinux Too bad you haven't even read a part of the article.
    - vlovich123 2y ago
      I was responding to what OP wrote: > Redhat and Gentoo are the only ones that officially support it afaik
kbolino 2y ago
Gentoo added some excellent and fairly distro-neutral documentation for SELinux a few years ago which makes it somewhat viable outside of Red Hat. It's also helpful for debugging issues even on Red Hat. https://wiki.gentoo.org/wiki/SELinux https://wiki.gentoo.org/wiki/SELinux
INTPenis 2y ago
It's unfortunately "broken" on purpose even on RHEL. Red Hat have made decisions to run init services in unrestricted context just to make it easier for their end clients to deploy their own services without needing SElinux modules. In my view all these compromimses only speak to the true security of SElinux. The fact that we need to have a website called https://stopdisablingselinux.com/ https://stopdisablingselinux.com/ means it's working! I am one of those weirdos who prefers to learn and adapt to SElinux instead of disabling it. The article in question takes a lot of liberties with complete FS access. It's not really applicable to real world server security. The focus is on smartphones.
- tetha 2y ago
  Mh. I know Linux and SELinux. SELinux has a severe documentation issue. Like, as a user, once you grok filesystem, port and process tags, it's easy to navigate most if not all common "strange" SELinux errors. After that I figured, I might be able to implement SELinux modules for our in-house services. Just tag config files, binaries, logfiles, state files, add a tag for the process, link them up with a few rules, easy peasy I all in all hit a wall harder than the iron curtain. I'd have to understand my application on an individual syscall level (I think, from like one github gist and a random dudes blogpost going into a few details to implement selinux modules) to do anything at that level. I spent a week on that and figured that I either have to understand kernel interfaces and the entire SELinux stack in all details to implement my own SELinux modules, or to not implement my own SELinux modules. At that point I figured no one else on the team would have a snowballs chance in hell to do any of what I'm looking at and accepted SELinux would not be a thing for our internal applications.

totony 2y ago

Most distros use https://github.com/SELinuxProject/refpolicy https://github.com/SELinuxProject/refpolicy while RHEL uses https://github.com/fedora-selinux/selinux-policy https://github.com/fedora-selinux/selinux-policy It's also my experience that Fedora has better support for it, but Gentoo used to be good enough with hardened gentoo (they use https://gitweb.gentoo.org/proj/hardened-refpolicy.git/ https://gitweb.gentoo.org/proj/hardened-refpolicy.git/). Redhat and Gentoo are the only ones that officially support it afaik. I think hardened gentoo might have lost popularity since the fall of grsec, but I'm not sure how popular it is currently.

vlovich123 2y ago
FWIW Android also uses SELinux & I believe selinux-policy. Have no idea about the quality of the implementation.
- BSDobelix 2y ago
  >Android also uses SELinux Too bad you haven't even read a part of the article.
  - vlovich123 2y ago
    I was responding to what OP wrote: > Redhat and Gentoo are the only ones that officially support it afaik

kbolino 2y ago

Gentoo added some excellent and fairly distro-neutral documentation for SELinux a few years ago which makes it somewhat viable outside of Red Hat. It's also helpful for debugging issues even on Red Hat. https://wiki.gentoo.org/wiki/SELinux https://wiki.gentoo.org/wiki/SELinux

INTPenis 2y ago

It's unfortunately "broken" on purpose even on RHEL. Red Hat have made decisions to run init services in unrestricted context just to make it easier for their end clients to deploy their own services without needing SElinux modules. In my view all these compromimses only speak to the true security of SElinux. The fact that we need to have a website called https://stopdisablingselinux.com/ https://stopdisablingselinux.com/ means it's working! I am one of those weirdos who prefers to learn and adapt to SElinux instead of disabling it. The article in question takes a lot of liberties with complete FS access. It's not really applicable to real world server security. The focus is on smartphones.

tetha 2y ago
Mh. I know Linux and SELinux. SELinux has a severe documentation issue. Like, as a user, once you grok filesystem, port and process tags, it's easy to navigate most if not all common "strange" SELinux errors. After that I figured, I might be able to implement SELinux modules for our in-house services. Just tag config files, binaries, logfiles, state files, add a tag for the process, link them up with a few rules, easy peasy I all in all hit a wall harder than the iron curtain. I'd have to understand my application on an individual syscall level (I think, from like one github gist and a random dudes blogpost going into a few details to implement selinux modules) to do anything at that level. I spent a week on that and figured that I either have to understand kernel interfaces and the entire SELinux stack in all details to implement my own SELinux modules, or to not implement my own SELinux modules. At that point I figured no one else on the team would have a snowballs chance in hell to do any of what I'm looking at and accepted SELinux would not be a thing for our internal applications.