Hacker News Reader

Comment by wannacboatmovie | Hacker News Reader

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.

View on HN

Most distros use https://github.com/SELinuxProject/refpolicy while RHEL uses 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/). 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.

FWIW Android also uses SELinux & I believe selinux-policy. Have no idea about the quality of the implementation.

>Android also uses SELinux

Too bad you haven't even read a part of the article.

I was responding to what OP wrote:

> Redhat and Gentoo are the only ones that officially support it afaik

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

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

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.

Reply on news.ycombinator.com