Description of problem: Starting freshly provisioned Fedora rawhide produces AVC denials in the audit.log. Version-Release number of selected component (if applicable): chrony-3.1-5.fc27.x86_64 selinux-policy-3.13.1-252.fc27.noarch How reproducible: Deterministic. Steps to Reproduce: 1. Provision Fedora rawhide. 2. Check audit.log. Actual results: type=AVC msg=audit(1494331724.866:101): avc: denied { dac_read_search } for pid=947 comm="chronyc" capability=2 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:chronyd_t:s0 tclass=capability permissive=0 type=AVC msg=audit(1494331724.866:100): avc: denied { dac_read_search } for pid=947 comm="chronyc" capability=2 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:chronyd_t:s0 tclass=capability permissive=0 type=AVC msg=audit(1494331724.866:102): avc: denied { dac_read_search } for pid=947 comm="chronyc" capability=2 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:chronyd_t:s0 tclass=capability permissive=0 type=AVC msg=audit(1494331724.866:103): avc: denied { dac_read_search } for pid=947 comm="chronyc" capability=2 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:chronyd_t:s0 tclass=capability permissive=0 type=AVC msg=audit(1494331724.867:104): avc: denied { dac_read_search } for pid=947 comm="chronyc" capability=2 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:chronyd_t:s0 tclass=capability permissive=0 type=AVC msg=audit(1494331724.913:105): avc: denied { dac_read_search } for pid=961 comm="chronyc" capability=2 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:chronyd_t:s0 tclass=capability permissive=0 type=AVC msg=audit(1494331724.913:106): avc: denied { dac_read_search } for pid=961 comm="chronyc" capability=2 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:chronyd_t:s0 tclass=capability permissive=0 Expected results: No AVC denials. Additional info:
Filed against chrony in case the fix should be to actually avoid dac_read_search.
With the same nvr of selinux-policy, I have seen AVC denied { dac_read_search } for the following comms: unix_chkpwd systemd-logind sm-notify Maybe it is actually an selinux-policy issue?
This seems to be related to some change in the kernel in handling of Unix domain sockets. If chronyc is using only INET sockets, it doesn't produce the AVC message. Downgrading the kernel to a 4.11 package fixes the problem for me. I'm not sure if it's actually a bug in the kernel or the selinux policy just needs an update for this change. The other recent bugs with dac_read_search are probably duplicates.
These avc started to show up after this commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a4c22426955d4fc04069811997b7390c0fb858e 2a4c22426955d4fc04069811997b7390c0fb858e is the first bad commit commit 2a4c22426955d4fc04069811997b7390c0fb858e Author: Stephen Smalley <sds.gov> Date: Fri Mar 10 12:14:18 2017 -0500 fs: switch order of CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH checks generic_permission() presently checks CAP_DAC_OVERRIDE prior to CAP_DAC_READ_SEARCH. This can cause misleading audit messages when using a LSM such as SELinux or AppArmor, since CAP_DAC_OVERRIDE may not be required for the operation. Flip the order of the tests so that CAP_DAC_OVERRIDE is only checked when required for the operation. Signed-off-by: Stephen Smalley <sds.gov> Acked-by: John Johansen <john.johansen> Reviewed-by: Serge Hallyn <serge> Acked-by: James Morris <james.l.morris> Signed-off-by: Paul Moore <paul>
Ok, if this is an intentional change in the kernel, I guess the selinux policy needs to be updated.
We seem to be hitting the exact opposite of what that commit is fixing, i.e. process has CAP_DAC_OVERRIDE, but doesn't have CAP_DAC_READ_SEARCH and a check for the latter produces an AVC warning. While this probably can be fixed by a policy update or per-package permissions fixes, it doesn't sound right to get avcs even though the process has valid capabilities.
Is there any kernel bugzilla for this? While the patch did something like this on purpose. The fact that it is checking CAP_DAC_READ_SEARCH when it should not (and even did not before) does not look like an intentional behaviour of the patch, here. I rather think this should be fixed in kernel.
Let's reassign the bug to the kernel again.
First a quick question: what kernel version/release are you running? Second, it seems like the fix is to modify SELinux policy to grant the capability:dac_read_search permission, what am I missing? Why is this a kernel bug?
(In reply to Paul Moore from comment #11) > First a quick question: what kernel version/release are you running? Anything starting with 4.12-rc1 and up > Second, it seems like the fix is to modify SELinux policy to grant the > capability:dac_read_search permission, what am I missing? Why is this a > kernel bug? It is as much a kernel bug as it was before the commit mentioned in comment #6. If I read it correctly that patch just moves the problem from CAP_DAC_OVERRIDE to CAP_DAC_READ_SEARCH, thus fixing some policies and breaking the others. Maybe generic_permission() needs a version of capable_wrt_inode_uidgid that would use ns_capable_noaudit instead of ns_capable for the first check?
The kernel commit, while perhaps inconvenient, is the right thing to do, let's fix this via policy.
Is there no way to do something like 'pass if CAP_DAC_OVERRIDE _or_ CAP_DAC_READ_SEARCH is defined' so that it does not break the old case? This does break a lot of policies, not just chronyd --I have seen this with e.g. postfix or syslogd as well.
That isn't something we like doing in the kernel, the Right Thing to do is to update the policies.
Could we get the policies updated?
Any chance of getting the fix to rawhide? The bug is affecting our automated testing.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
I no longer see this issue with selinux-policy-3.13.1-283.34.fc27.noarch. Should this bugzilla be closed CURRENTRELEASE, with some fixed in version set?
Agree with Jan. Thanks.