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?
# everything maps etc_t for /etc/passwd and /etc/group
allow chkpwd_t etc_t:file map;
allow chkpwd_t shadow_t:file map;
allow consolekit_t etc_t:file map;
allow local_login_t etc_t:file map;
allow system_sudo_t etc_t:file map;
allow systemd_logind_t etc_t:file map;
allow systemd_tmpfiles_t etc_t:file map;
allow getty_t etc_t:file map;
allow crond_t etc_t:file map;
allow audisp_t etc_t:file map;
allow mon_t etc_t:file map;
allow postfix_bounce_t etc_t:file map;
allow postfix_cleanup_t etc_t:file map;
allow postfix_local_t etc_t:file map;
allow postfix_master_t etc_t:file map;
allow postfix_pickup_t etc_t:file map;
allow postfix_postdrop_t etc_t:file map;
allow postfix_qmgr_t etc_t:file map;
allow semanage_t etc_t:file map;
allow sshd_t etc_t:file map;
allow syslogd_t etc_t:file map;
allow system_dbusd_t etc_t:file map;
allow system_mail_t etc_t:file map;
allow auditd_t etc_t:file map;
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On Sat, Nov 04, 2017 at 08:17:53PM +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?
>
> # everything maps etc_t for /etc/passwd and /etc/group
> allow chkpwd_t etc_t:file map;
> allow chkpwd_t shadow_t:file map;
> allow consolekit_t etc_t:file map;
> allow local_login_t etc_t:file map;
> allow system_sudo_t etc_t:file map;
> allow systemd_logind_t etc_t:file map;
> allow systemd_tmpfiles_t etc_t:file map;
> allow getty_t etc_t:file map;
> allow crond_t etc_t:file map;
> allow audisp_t etc_t:file map;
> allow mon_t etc_t:file map;
> allow postfix_bounce_t etc_t:file map;
> allow postfix_cleanup_t etc_t:file map;
> allow postfix_local_t etc_t:file map;
> allow postfix_master_t etc_t:file map;
> allow postfix_pickup_t etc_t:file map;
> allow postfix_postdrop_t etc_t:file map;
> allow postfix_qmgr_t etc_t:file map;
> allow semanage_t etc_t:file map;
> allow sshd_t etc_t:file map;
> allow syslogd_t etc_t:file map;
> allow system_dbusd_t etc_t:file map;
> allow system_mail_t etc_t:file map;
> allow auditd_t etc_t:file map;
What does your /etc/nsswitch.conf look like? do you have "compat" for
passwd, shadow, group? it maps a lot but doesnt acutally need it.
If you switch it to this then you wont get any maps at all:
passwd: files
shadow: files
group: files
-- Jason
On Sat, 04 Nov 2017 20:17:53 +1100
Russell Coker via refpolicy <[email protected]> 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
On Saturday, 4 November 2017 8:46:10 PM AEDT Jason Zaman wrote:
> What does your /etc/nsswitch.conf look like? do you have "compat" for
> passwd, shadow, group? it maps a lot but doesnt acutally need it.
> If you switch it to this then you wont get any maps at all:
>
> passwd: files
> shadow: files
> group: files
Thanks Jason and Luis. I've tested that and it works for me.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880846
I've filed the above Debian bug report requesting that this be made the
default. NIS is hardly ever used nowadays and the people with the rare and
unusual configurations for NIS are surely capable of changing the
nsswitch.conf file along with the many other changes they need to make to
support NIS.
For Buster I'll probably need to make the selinux-activate script do
s/compat/files/ .
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On 04/11/17 21:16, Luis Ressel via refpolicy wrote:
> On Sat, 04 Nov 2017 20:17:53 +1100
> Russell Coker via refpolicy <[email protected]> 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
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 <[email protected]> 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
On Sun, 5 Nov 2017 13:09:58 -0500
Chris PeBenito via refpolicy <[email protected]> wrote:
> Thanks for looking in to that. I'm inclined to dontaudit all that
> stuff.
The only remaining question is whether we actually care about this.
With the 2.26 release, glibc has deprecated libnss_compat, which was
the source of this denial spam.
If a dontaudit is added, I'd suggest to add a comment alongside it
stating that the dontaudit should be removed again (in 1-2 years,
perhaps?).
Regards,
Luis Ressel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20171114/34920dc4/attachment.bin
On 11/13/2017 09:56 PM, Luis Ressel wrote:
> On Sun, 5 Nov 2017 13:09:58 -0500
> Chris PeBenito via refpolicy <[email protected]> wrote:
>
>> Thanks for looking in to that. I'm inclined to dontaudit all that
>> stuff.
>
> The only remaining question is whether we actually care about this.
> With the 2.26 release, glibc has deprecated libnss_compat, which was
> the source of this denial spam.
>
> If a dontaudit is added, I'd suggest to add a comment alongside it
> stating that the dontaudit should be removed again (in 1-2 years,
> perhaps?).
In that case, I'd say no dontaudits. 2.26 didn't just come out
yesterday, it came out 3 months ago.
--
Chris PeBenito