This means SELinux checks happen before normal ownership/permission checks. I always prefer to have the DAC check happen first. This is important because code that is attempting the denied access usually will handle the EPERM silently and go down a different code path. But if a MAC Failure happens, SELinux writes an AVC to the audit log, and setroubleshoot reports it to the user.
One of the biggest offenders of this was the mmap_zero check. Every time a process tries to map low kernel memory, the kernel denies it, in both DAC and MAC. Wine applications are notorious for this. We block mmap_zero because it can potentially trigger kernel bugs which can lead to privilege escalation.
Eric Paris explains the vulnerability here.
Since the MAC check was done before the DAC check, the wine applications tend to work correctly. When the wine application attempts to mmap low memory, it gets denied, and then reattempts the mmap with a higher memory value. On an SELinux system the kernel generates AVC. The user sees something like:
SELinux is preventing /usr/bin/wine-preloader from 'mmap_zero' accesses on the memprotect.
Reading about the mmap_zero, scares the user and they think their machine is vulnerable. The only thing SELinux policy writers can do is write a dontaudit rule or allow the access, which defeats the purpose of the check.
We still want to block this access if a privileged confined process got it and report the SELinux violation. If an confined application running as root, attempts a mmap_zero access, SELinux should block it and report the AVC. If a normal unprivileged process triggered the access check, we would prefer to allow DAC to handle it, and not print the message.
To give you an idea of how often people have seen this; Google "SELinux mmap_zero" and you will get more then 13,000 hits.
Today the upstream kernel has been fixed to report check for mmap_zero for MAC AFTER DAC.
Thanks to Eric Paris and Paul Moore for fixing this issue.