I'm working on limiting capabilities of an existing, complex application and I have been searching for a while for a credible source proving that
permissions included in cap_dac_override
are a superset of cap_dac_read_search
.
It seems logical that it is indeed the case, as per capabilities(7)
:
CAP_DAC_OVERRIDE
* Bypass file read, write, and execute permission checks.CAP_DAC_READ_SEARCH
* Bypass file read permission checks and directory read and execute permission checks;
* invoke open_by_handle_at(2);
* use the linkat(2) AT_EMPTY_PATH flag to create a link to a file referred to by a file descriptor.
Also, my experiments with capability checks tracer confirm that cap_dac_override
should suffice. cap_dac_read_search
appears to be checked before cap_dac_override
every single time a read access is performed.
I've also found following post on grsecurity forums, which unfortunetly concerns only /proc
:
The way the upstream kernel works is by first checking for CAP_DAC_OVERRIDE and then for CAP_DAC_READ_SEARCH for this case.
I'm still uncertain whether is it completely safe to omit cap_dac_read_search
if I want to grant my application with a complete read access to the whole filesystem. I'm fully aware that cap_dac_override
additionally grants write permissions, and I want that.
Would it be possible that somwhere in the kernel there is a place where only a check for cap_dac_read_search
is made and not for cap_dac_override
?
Should I include both these capabilities just to be on the safe side or is cap_dac_read_search
completely redundant in this case?