From: pebenito@ieee.org (Chris PeBenito)
Date: Sun, 5 Nov 2017 13:09:58 -0500
Subject: [refpolicy] map permissions
In-Reply-To: <472df9ba-2110-39ca-e540-4b165c4648c9@m4x.org>
References: <3850548.JCvBVk9sDr@xev>
	<20171104211601.083a0a96@vega.skynet.aixah.de>
	<472df9ba-2110-39ca-e540-4b165c4648c9@m4x.org>
Message-ID: <9767fc1e-3461-6c6f-dc40-329fec8652e4@ieee.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 11/05/2017 05:44 AM, Nicolas Iooss via refpolicy wrote:
> On 04/11/17 21:16, Luis Ressel via refpolicy wrote:
>> On Sat, 04 Nov 2017 20:17:53 +1100
>> Russell Coker via refpolicy <refpolicy@oss.tresys.com> wrote:
>>
>>> http://oss.tresys.com/pipermail/refpolicy/2017-May/009534.html
>>>
>>> What happened to the patch from the above message?  The glibc
>>> implementations of getpwent(3) and friends map files so I have the
>>> following on a test machine.  If we aren't going to add the patch
>>> from the above message to allow map for most read permissions then I
>>> think we should do it for etc_t at least if we aren't going to allow
>>> it for all reads.  If so we could have a _nomap variant of interfaces
>>> for reading etc_t for the rare programs that can operate without
>>> getpwent(3) etc.
>>>
>>> What do you think?
>>>
>>> As an aside, am I the only person here testing with recent kernels?
>>
>> No, you aren't. Just have a look at all the map-related patches
>> submitted to this ML in the past months. :)
>>
>> The getpwent problem was discussed in the thread "file map perm issues"
>> started on September 10. TL;DR: "etc_t:file map" isn't neccessary at
>> all if you disable compat mode in nsswitch.conf, and even in compat
>> mode, the denials appear to be nonfatal as long as netgroups aren't
>> used. Somone needs to check the code to verify this, and then we can
>> probably just dontaudit the permission.
>>
>> In general, Chris said he'd prefer it if interfaces granting read
>> access don't automatically grant map access, too; instead, he'd like to
>> see separate interface to grant the map permission when required.
> 
> "Someone needs to check the code to verify this": here is what I see in
> glibc's code:
> 
> * nss_files uses fopen (DATAFILE, "rce"); [1] ("c" means "not cancel"
> and "e" "CLOEXEC")
> * nss_compat uses fopen ("/etc/passwd", "rme"); [2] ("m" means "mmap if
> possible")
> * the call to mmap for files opened with mode "m" occurs in
> decide_maybe_mmap() [3] and if it fails, it falls back to non-mmap
> operations.
> 
> Therefore the denials which are seen do not seem to be fatal in programs
> using glibc.

Thanks for looking in to that.  I'm inclined to dontaudit all that stuff.

-- 
Chris PeBenito