From: aranea@aixah.de (Luis Ressel) Date: Sat, 4 Nov 2017 21:16:01 +0100 Subject: [refpolicy] map permissions In-Reply-To: <3850548.JCvBVk9sDr@xev> References: <3850548.JCvBVk9sDr@xev> Message-ID: <20171104211601.083a0a96@vega.skynet.aixah.de> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Sat, 04 Nov 2017 20:17:53 +1100 Russell Coker via refpolicy 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. Cheers, Luis Ressel