> With my very limited knowledge of selinux, I don't follow. > Why it would need DAC_READ_SEARCH? If you can provide an example, it > would be great.
postfix services like smtp, smtpd, postfix-master and tlsproxy need access to `/var/spool/postfix/private/proxymap` and the parent directory `/var/spool/postfix/private/` is owned by postfix:root with mode 0700. Thus processes running as root:root have no standard DAC search permission for that directory (they are not the owner and there are no group and other permissions) so the kernel checks access via capabilities. For directory search permission DAC_READ_SEARCH is considered first, but this capability is not granted via the systemd service file. Then DAC_OVERRIDE is tried, which is granted via the systemd service file, and finally directory search access is granted. With an active LSM each capability is checked whether its granted by the loaded security policy. So with DAC_READ_SEARCH not granted, since its not in the permitted capability set, SELinux is queried with DAC_OVERRIDE. Previously, or with DAC_READ_SEARCH added to the permitted capability set, SELinux is queried with DAC_READ_SEARCH, leading to a less permissive policy only granting DAC_READ_SEARCH and not DAC_OVERRIDE. Also adding DAC_READ_SEARCH to the permitted capability set does not expand privileges since the kernel always falls back to DAC_OVERRIDE. p.s.: please send BTS mails also to nnn-submit...@bugs.debian.org
