I am working on some Android customizations and an app I am writing causes a dac_override which looks like so in dmesg:

type=1400 audit(499405.329:16): avc: denied { dac_override } for 
pid=1103 comm="my_tool" capability=1 scontext=u:r:my_tool:s0
tcontext=u:r:my_tool:s0 tclass=capability permissive=1

I know the executable that is causing the problem (it's my_tool) and I know that dac_override means that the executable doesn't have traditional linux permissions to perform some operation, but I don't know which operation was attempted and which file it was attempted on. How can I find out?

Also as a side question I assume by the name and the behavior that dac_override means that SELinux has the capability to override traditional linux permission violations?

  • so were you able to find a way? – 4aRk Kn1gh7 Jan 1 at 13:06
  • 1
    I could not find an obvious solution, I had to use intuition. I would still like appreciate if anyone has a proper scientific solution. – satur9nine Jan 3 at 0:38

The systematic way would be to

1) Set SELinux to enforcing via setenforce 1. The SELinux violation should then make the corresponding syscall in my_tool fail. You can use getenforce to verify this succeeded.

2) Run your my_tool with strace to identify the failing syscall, e.g. strace my_tool 2>&1 | grep '= -'.

In my case, I have the following violation: type=1400 msg=audit(4816808.488:3): avc: denied { dac_override } for pid=123 comm="my_tool" capability=1 scontext=u:r:my_tool:s0 tcontext=u:r:my_tool:s0 tclass=capability permissive=0

Running strace my_tool 2>&1 | grep '= -' gives

openat(AT_FDCWD, "/some/file", some_mode) = -1 EINVAL (Invalid argument)

Using ls -l /some/file confirms the file is owned by the system user whereas my_tool is running as root and that the DAC permissions of this file do not intend to allow access by other users. Of course, the root user bypasses this restrictions, but it generates the dac_overwrite violation in SELinux (reference). So concerning your last question: SELinux does not allow to bypass traditional DAC permissions, but it can be used to enforce them even for the root user.

Of course, the effectiveness of this approach to some extend depends on the complexity of my_tool, i.e. how many other failing syscalls it deals with during normal operation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.