I see a few obvious areas of improvement, all of which are "implementation details" and don't undermine the core principles of SELinux. > The SELinux denial au

I see a few obvious areas of improvement, all of which are "implementation details" and don't undermine the core principles of SELinux. > The SELinux denial audit log messages are too vague. You’re told that a label was denied reading from another label. Okay, what do those labels mean? Which programs? Which files, sockets, or whatever? Improve logging in the SELinux system. Clearly it was able to map the program/files to labels, why aren't those programs/files provided in the error message? > There’s nowhere on the system where you can view the policies and look up why something might or might not work. Improve SELinux's policy analysis tools. As it is, it appears `seinfo` and `sesearch` provide too much detail and are impossible for non-experts to use. Are there alternatives that any sysadmin can use? > A package’s SELinux policy is — most often — not part of the package but is installed as part of a larger meta package containing tens of thousands of policies (e.g., the Fedora Linux project’s selinux-policy mega-package). Policy should be included with the software package (or have a clear, computer-resolvable link to the package the policy applies to). Seems to me that SELinux is an afterthought in most distributions, which I can understand in volunteer/community-driven distributions, less in Enterprise ones. How does RHEL do it? -- However, the fact that these problems remain decades after the introduction of SELinux (2000!), indicate a lack of will by the Enterprise Linux/Security industry. Considering its origins at NSA, which I'm sure is willing to train its sysadmins and not bothered by its obtuseness, I'm not surprised.