[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!