> Now, most sysadmins are probably not aware of SELinux nor its policy set until they can’t achieve something because it violates the policies. First, many app

> Now, most sysadmins are probably not aware of SELinux nor its policy set until they can’t achieve something because it violates the policies. First, many applications come with SELinux policies. For the ones that don't, users will need to create a pipeline. When I've written custom apps I usually have a "soak test" pipeline whereby the application runs through all of its commands and configuration and we capture denials, produce a policy with audit2allow and then review the syscalls to ensure they match what we'd expect from the application. If you're logging into a box or receiving an OS image that has SELinux turned on and you don't know how to query, that bit is just a lack of knowledge. It's a very simple command and there's a finite number of modes. The wider problem is that enterprises beyond FAANG have a very tough time perceiving systems as a product or systems engineers as anything beyond advanced troubleshooters. That's why you get these huge OS bakeries that ship out a cookie cutter system that everyone must use, or else. This is all usually motivated by compliance. On top of that, while at enterprises I've noticed that they'll teach all the courses in the world about programming and databases yet there's conspicuously no classes to hone your skills as a systems engineer. The pipeline I mentioned earlier isn't magic, I came up with the idea because I understand the workflow of SELinux and I know enough about syscalls to interrogate my own code. It's kind of like the people who like to read machine code and compare it to their application but for a systems engineer. There should be classes for the kernel and userland alike. Point being, because enterprises commonly view the system as a checkbox rather than a product, or worse produce an undocumented cookie cutter product with "best practices" it harms the profession of systems engineering. Coincidentally, this is also why I mainly use the title "Software Engineer" rather than "Systems Engineer" with big corps.