From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <530F9359.9020505@redhat.com> Date: Thu, 27 Feb 2014 14:34:49 -0500 From: Daniel J Walsh MIME-Version: 1.0 To: Paul Moore , Stephen Smalley Subject: Re: [PATCH] selinux: put the mmap() DAC controls before the MAC controls References: <20140227143045.14242.66994.stgit@localhost> <2802481.ZiEtmME2xN@sifl> <530F673B.5080906@tycho.nsa.gov> <3974420.4TmIcvnhqi@sifl> In-Reply-To: <3974420.4TmIcvnhqi@sifl> Content-Type: text/plain; charset=ISO-8859-1 Cc: casey.schaufler@intel.com, selinux@tycho.nsa.gov List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 ). 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMPk1kACgkQrlYvE4MpobPVwACfZQGC8tldE6F5PXKLeYgELrYT t28An21+GMg/0Jipe+8TLiKcHuBSYLM1 =TwuX -----END PGP SIGNATURE-----