On 02/27/2014 02:52 PM, Stephen Smalley wrote: > On 02/27/2014 02:34 PM, Daniel J Walsh wrote: >> On 02/27/2014 02:25 PM, Paul Moore wrote: >>> On Thursday, February 27, 2014 11:26:35 AM Stephen Smalley wrote: >>>> On 02/27/2014 11:22 AM, Paul Moore wrote: >>>>> On Thursday, February 27, 2014 10:57:46 AM Stephen Smalley wrote: >>>>>> On 02/27/2014 09:30 AM, Paul Moore wrote: >>>>>>> It turns out that doing the SELinux MAC checks for mmap() before >>>>>>> the DAC checks was causing users and the SELinux policy folks >>>>>>> headaches as users were seeing a lot of SELinux AVC denials for >>>>>>> the memprotect:mmap_zero permission that would have also been >>>>>>> denied by the normal DAC capability checks (CAP_SYS_RAWIO). >>>>>> >>>>>> So you think that the explanation given in the comment for the >>>>>> current ordering is no longer valid? >>>>> >>>>> Yes and no. Arguably there is still some value in it but there are >>>>> enough problems with it as-is that I think the value is starting to be >>>>> outweighed by the pain it is causing (Dan can be very annoying when he >>>>> wants something <g>). For those users who still want notification of >>>>> processes trying to mmap() low addresses, I think an audit watch is a >>>>> much better approach. I don't think SELinux shouldn't be acting as an >>>>> intrustion detection tool when we have other things that do that job. >>>>> >>>>> Let's also not forget that the MAC-before-DAC approach goes against >>>>> the general approach to applying SELinux controls, so there is some >>>>> argument to be had for consistency as well. >>>>> >>>>> Do you have a strong objection to this patch? >>>> >>>> No, although I do wonder if we ought to just dispense with mmap_zero >>>> altogether at this point. It made sense when there was no capability >>>> check or if the capability was one of the extremely broad ones (e.g. >>>> CAP_SYS_ADMIN), but I don't really see why we can't be just as >>>> restrictive with CAP_SYS_RAWIO / sys_rawio as with mmap_zero. >> >>> Seems like a reasonable argument to me. I pinged Eric to get his thoughts >>> on the issue since he added the check originally; if he is okay with >>> removing it, I'll go ahead do it. >> >> The only thing is this is a nice debugging tool for the kernel. Finding apps >> that accidentally mmap_zero. > > You'll still see sys_rawio avc denials and the audit syscall record will > show that it was mmap of a low address. Looking at Fedora policy, there are differences in what domains are allowed mmap_zero vs sys_rawio, although I don't know how intentional/meaningful that is. sesearch -A -p mmap_zero vs sesearch -A -p sys_rawio Why for example does cupsd_t have sys_rawio? That's rather disturbing. I guess you should keep the separate check until those differences are resolved. _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
