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 co

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_enterprise_linux/9-beta/html/using_selinux/troubleshooting-problems-related-to-selinux_using-selinux#identifying-selinux-denials_troubleshooting-problems-related-to-selinux 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 }