Bug 1285339

Summary:	nss_mymachines can poison the nscd cache
Product:	[Fedora] Fedora	Reporter:	Florian Weimer <fweimer>
Component:	glibc	Assignee:	glibc team <glibc-bugzilla>
Status:	CLOSED WORKSFORME	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	arjun.is, codonell, dj, fweimer, jakub, johannbg, law, lnykryn, lpoetter, mfabian, msekleta, pfrankli, siddhesh, s, ssorce, systemd-maint, zbyszek
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-10-30 13:23:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1285267

Description Florian Weimer 2015-11-25 12:26:16 UTC

on Fedora rawhide, with SELinux in non-enforcing mode (due to bug
1285267), nscd enabled, and nss_mymachines in /etc/nsswitch.conf (per
bug 1284325), and a container foo1 running, this happens:

[root@localhost fweimer]# nscd -i passwd
[root@localhost fweimer]# nscd -i group
[root@localhost fweimer]# ls -ld /root
dr-xr-x---. 3 root root 163 Nov 25 11:19 /root
[root@localhost fweimer]# getent passwd vu-foo1-0
vu-foo1-0:*:0:65534:vu-foo1-0:/:/sbin/nologin
[root@localhost fweimer]# getent group vg-foo1-0
vg-foo1-0:*:0:
[root@localhost fweimer]# ls -ld /root
dr-xr-x---. 3 vu-foo1-0 vg-foo1-0 163 Nov 25 11:19 /root
[root@localhost fweimer]# getent passwd 0
vu-foo1-0:*:0:65534:vu-foo1-0:/:/sbin/nologin
[root@localhost fweimer]# getent group 0
vg-foo1-0:*:0:
[root@localhost fweimer]# nscd -i passwd
[root@localhost fweimer]# nscd -i group
[root@localhost fweimer]# getent passwd 0
root:x:0:0:root:/root:/bin/bash
[root@localhost fweimer]# getent group 0
root:x:0:

That is, nss_mymachines poisons the reverse lookup of system UIDs and
GIDs (any UID or GID, basically) until the cache is invalidated.

I'm not sure if this needs a CVE ID because nss_mymachines is currently
incompatible with SELinux in enforcing mode, and nscd does not run by
default.  I don't know if any ships this code yet.

Comment 1 Lennart Poettering 2016-02-10 21:40:12 UTC

Hmm, which container manager is this? nspawn? docker?

Did you use user namespacing in the container?

Comment 2 Lennart Poettering 2016-02-10 21:58:35 UTC

Apparently there's no NSS entry point that would allow us to pass a TTL for each user or group, like there is for host lookups. This is nasty, and means outdated user/group data might linger uncontrolled. But that's really breakage in nscd that needs to be fixed there.

Other than that, I will now change nss-mymachines so that it will it exclude itself from all lookups if no user translation actually took place, or if the translated users is < 0x10000 (which we consider strictly private the host UIDs). This should guarantee that nss-mymachines can never be used to create nscd cache records for UIDs outside of ranges that are explicitly assigned for user namespace mappings.

Comment 3 Florian Weimer 2016-02-10 22:30:07 UTC

(In reply to Lennart Poettering from comment #1)
> Hmm, which container manager is this? nspawn? docker?

systemd-nspwan, without --private-users.

Comment 4 Lennart Poettering 2016-02-11 10:55:29 UTC

THe mentioned fix is here:

https://github.com/systemd/systemd/pull/2576

Comment 5 Lennart Poettering 2016-02-11 16:03:16 UTC

The fix went in now. I'll consider this fixed from the systemd perspective. 

Will now reassign to glibc, since we cannot solve this fully unless nscd provides a way to set a ttl for grp/pwd entries passed to it, the same way it supports it for hosts entries...

Comment 6 Florian Weimer 2016-02-11 16:59:05 UTC

(In reply to Lennart Poettering from comment #5)
> The fix went in now. I'll consider this fixed from the systemd perspective. 
> 
> Will now reassign to glibc, since we cannot solve this fully unless nscd
> provides a way to set a ttl for grp/pwd entries passed to it, the same way
> it supports it for hosts entries...

For the host cache, NetworkManager needs to signal nscd when the DNS view changes.  TTL support is insufficient.

Will something similar be needed for the user and group database?  You can't predict container lifetime, so I don't see how you want to set a correct TTL.

Comment 7 Jan Kurik 2016-02-24 14:01:32 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Comment 8 Florian Weimer 2016-05-25 08:36:02 UTC

(In reply to Florian Weimer from comment #6)
> (In reply to Lennart Poettering from comment #5)
> > The fix went in now. I'll consider this fixed from the systemd perspective. 
> > 
> > Will now reassign to glibc, since we cannot solve this fully unless nscd
> > provides a way to set a ttl for grp/pwd entries passed to it, the same way
> > it supports it for hosts entries...
> 
> For the host cache, NetworkManager needs to signal nscd when the DNS view
> changes.  TTL support is insufficient.
> 
> Will something similar be needed for the user and group database?  You can't
> predict container lifetime, so I don't see how you want to set a correct TTL.

Lennart?

Comment 9 Lennart Poettering 2016-06-06 17:50:28 UTC

(In reply to Florian Weimer from comment #6)

> Will something similar be needed for the user and group database?  You can't
> predict container lifetime, so I don't see how you want to set a correct TTL.

I'd simply set the TTL to 0, so that nscd doesn't cache at all. There's really no point in caching stuff that is a quick local check anyway.

Comment 10 Fedora End Of Life 2017-07-25 19:33:40 UTC

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 11 Florian Weimer 2019-10-30 13:19:36 UTC

The systemd fix was this:

commit cf3bdcfeba48ffef71f1f59e092c4fb9275dcb3a
Author: Lennart Poettering <lennart>
Date:   Wed Feb 10 22:58:41 2016 +0100

    nss-mymachines: never resolve unmapped UIDs/GIDs
    
    Don't ever permit successful user or group lookups if no UID/GID mapping is
    actually applied. THis way, we can be sure that nss-mymachines cannot be used
    to insert invalid cache entries into nscd's cache.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1285339

Comment 12 Florian Weimer 2019-10-30 13:23:36 UTC

I think the expiration problem needs a larger discussion about guaranteed propagation times for IdM updates and account revocation. So far, we have received no guidance on this matter and whether this is even a requirement.