3 ms·

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 e

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.

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.