From: nicolas.iooss@m4x.org (Nicolas Iooss)
Date: Sun, 5 Nov 2017 11:44:17 +0100
Subject: [refpolicy] map permissions
In-Reply-To: <20171104211601.083a0a96@vega.skynet.aixah.de>
References: <3850548.JCvBVk9sDr@xev>
	<20171104211601.083a0a96@vega.skynet.aixah.de>
Message-ID: <472df9ba-2110-39ca-e540-4b165c4648c9@m4x.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.
For your information, musl reads /etc/{passwd,groups,shadow} without
mmmap'ing them (and without using nsswitch).

Cheers,
Nicolas

[1]
https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/nss_files/files-XXX.c;hb=a1c7cd3c72e5002739161ba35c90944b3ad05c9f#l77
[2]
https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/nss_compat/compat-pwd.c;hb=a1c7cd3c72e5002739161ba35c90944b3ad05c9f#l224
[3]
https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/fileops.c;hb=a1c7cd3c72e5002739161ba35c90944b3ad05c9f#l692