Why all the DAC_READ_SEARCH AVC messages?
If you followed SELinux policy bugs being reported in bugzilla you might have noticed a spike in messages about random domains being denied DAC_READ_SEARCH.
Let's quickly look at what the DAC_READ_SEARCH capability is. In Linux the power of "root" was broken down into 64 distinct capabilities. Things like being able to load kernel modules or bind to ports less then 1024. Well DAC_READ_SEARCH is one of these.
DAC stands for Discretionary Access Control, which is what most people understand as standard Linux permissions, Every process has owner/group. All file system objects are assigned owner, group and permission flags. DAC_READ_SEARCH allows a privilege process to ignore parts of DAC for read and search.
* Bypass file read permission checks and directory read and execute permission checks;
There is another CAPABILITY called DAC_OVERRIDE
Bypass file read, write, and execute permission checks.
As you can see DAC_OVERRIDE is more powerful then DAC_READ_SEARCH, in that it can write and execute content ignoring DAC rules, as opposed to just reading the content.
Well why did we suddenly see a spike in confined domains needing DAC_READ_SEARCH?
Nothing in policy changed but the kernel changed. Basically the kernel was made a little more secure. Lets look at an example. There is a small program called unix_chkpwd (checkpwd_t) which you end up executing when you log into the system. This program reads /etc/shadow. On Fedora/RHEL/CentOS and probably other GNU/Linux systems, /etc/shadow has 0000 Mode. This means NO processes on the system, even if running as root (UID=0), are allowed to read/write /etc/shadow, unless they have a DAC Capability.
Well as policy evolved we saw that chckpwd_t needed to read /etc/shadow, it generated an DAC_OVERIDE AVC, so a policy developer gave that SELinux allow rule to checkpwd_t. And for years things worked properly but then the kernel changed...
If a process tried to read /etc/shadow, it would be allowed if it had either DAC_OVERRIDE or DAC_READ_SEARCH.
Older kernel's had pseudo code like
If DAC_OVERRIDE or DAC_READ_SEARCH:
Read a file with 0000 mode.
New Kernel switched to:
If DAC_READ_SEARCH or DAC_OVERRIDE
Read a file with 0000 mode.
Since the chkpwd_t had DAC_OVERRIDE in the older kernels, it never checked DAC_READ_SEARCH and therefore DAC_READ_SEARCH was never added to policy. Now it is checking DAC_READ_SEARCH first so we see the AVC being generated even though the final access was allowed.
This has generated a lot of noise for people from the SELinux logs, but really nothing got denied. After the AVC was generated the access was still allowed.
The policy package maintainers have been updating all of the policy to allow these new DAC_READ_SEARCH, and I have suggested to them to start dropping alot of DAC_OVERRIDE policy from domains, since a lot of them including chkpwd_t don't need to write /etc/shadow, so they should be able to get by with only reading it. This should eventually make SELinux policy more secure.