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

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.