In my previous blog
10 things you probably did not know about SELinux.. #7
I stated that one of the times you can get a syscall to succeed even though AVC's were generated was:
3. An AVC was generated but the syscall still succeeded by going down a different code path within the kernel. This is not that common.
Eric Paris pointed out to me in an email and example of this:
(People have a) " fundemental misconception is the belief that there is a 1-1 mapping between a syscall and an selinux permissions check. SELinux is NOT a syscall filter. We check the security state between objects (aka between a task and a file, or a task and a socket, or a task and task) and the result of that check may or may not cause the intended purpose of the request syscall which triggered this check to fail.
A great example of a syscall which is likely to generate AVCs but still give success=yes is execve(). On execve SELinux will check the permissions between the new task and any file descriptors passed from the parent to the child. Notice the check is not about the syscall, execve(), but between the new task and the file descriptors. If the new task is not allowed to access one of the passed file descriptors we will generate an AVC, and will close the fd and open /dev/null in it's place. This is an example of an alternate code path. The syscall is still going to succeed since we will have resolved the security violation that caused the AVC. It's not common, but other such places exist in the kernel, place where we are able to resolve the security issue by doing some other operation and thus the syscall does not need to fail."
Dan Walsh's Blog
- Follow up to #7 Does an SELinux Audit Log message always mean something was blocked?