Comment by egberts1
Biggest problem is the use of a SELinux compiler into components understood only by SELinux engine.
Does not help when the SELinux source text file is not buildable by function/procedure axiom: it is at its grittiest granularity, which ironically is the best kind of security, but only if composed by the most savviest SELinux system admins.
Often requires full knowledge of any static/dynamic libraries and any additional dynamic libraries it calls and its resource usages.
Additional frontend UI will be required to proactively determine suitability with those dynamic libraries before any ease of SELinux deployment.
For now, it is a trial and error in part on those intermediate system admins or younger.
From https://news.ycombinator.com/item?id=30025477 :
> [ audit2allow, https://stopdisablingselinux.com/ ]
Applications don't need to be compiled with selinux libraries unless they want to bypass CLI tools like chcon and restorecon (which set extended filesystem attributes according to the system policy; typically at package install time if the package provenance is sufficient) by linking with libselinux.