[ReganLaitila]

the linux fiefdoms have a serious UX problem. SELinux being a prime example. As the article articulates, no wonder why people just turn it off. If your subsystems are not consistent, discoverable, palpable, and most important logical your setting yourself up for lousy adoption. And just "reading the docs" does not solve this problem. Your subsystem does not get to consume my professional time slice.

The reason docker became the de facto entry point into containerization in yesteryear is because if you were dealing with 'containers' you were dealing with the 'docker' cli entry point. Everything you did with linux containers in the (mainstream) came from 'docker' and you can '--help' to your hearts content -or- google as much as you required with others that had the same shared experience with 'docker'. We've moved on in recent years but its important to remember the power of a well described, but imperfect interface.

SELinux has none of this mindshare. What is my canonical entrypoint to SELinux on any particular distro? There is none. I have to specifically know to install support packages for 'audit2allow' or 'audit2why' to do any reasonable troubleshooting on why a processes wont start. Why? Because any raw logs are so chocked with implementation details as a administrator I cannot make a real-world decision on what is broken on the system. Sysadmins do not start every day thinking about SELinux and memorizing its maze of tools and procedures. Something is starting to smell here...

For SELinux I need to know about, and sometimes explicitly install, half a dozen cli tools to administer selinux. Most of which don't follow any particular naming convention or entry point. I now need to learn a completely new markup for policy AND compile them AND install them using other esoteric tools . I need to explicitly refresh system state after making any changes, and return to my blunt 'audit2why' what-is-this tool to figure out if I did anything right.

The principles of SELinux are fine. The UX of SELinux in terms of getting shit done day to day is not.

[egberts1]

Right, right, and right.

Even after mastering all the fundamentals of SELinux, six month later a different audit-related problem surfaced and “what was that command again?”

This link often saves me:

https://access.redhat.com/documentation/en-us/red_hat_enterp...

In fact, I condensed it to the following steps (outlined elsewhere in this OP by patrck, new HN user):

couple sysadm red flags:

1) The article author is Testing in PROD

2) selinux debugging relies on auditd, so sanity checks required.

  df -P /var/log/audit # has space?
  tail -1 /var/log/audit/audit.log # is recent?
  semodule -DB  # disable dontaudit
  setenforce 0
  # run the failing test
  audit2allow -l

After which the selinux debugging experience boils down to:

    mk_semod() {
        module_name=$1; shift
        audit2allow -l -m ${module_name} -a > ${module_name}.te
        $EDITOR ${module_name}.te || return
        checkmodule -M -m -o ${module_name}.mod ${module_name}.te
        semodule_package -o ${module_name}.pp -m ${module_name}.mod
        semodule -i ${module_name}.pp
    }

[tremon]

The article author is Testing in PROD

when you acknowledge this, then continuing your advice with

  setenforce 0

is a spectacularly bad idea. You can make individual domains permissive using

  semanage permissive -a ${context}

and then run the failing test using only that permissive domain.

Of course, the story becomes much more complicated if the failing test requires type transitions -- but blanket advising people to put an entire PROD system in permissive mode is not a good idea.

[egberts1]

agreed on all points. sometime the problem is so elusive that its flipping it to `0` time!