Bug 1285339 - nss_mymachines can poison the nscd cache
nss_mymachines can poison the nscd cache
Status: NEW
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: glibc team
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks: 1285267
  Show dependency treegraph
 
Reported: 2015-11-25 07:26 EST by Florian Weimer
Modified: 2017-07-25 18:52 EDT (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Florian Weimer 2015-11-25 07:26:16 EST
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 16:40:12 EST
Hmm, which container manager is this? nspawn? docker?

Did you use user namespacing in the container?
Comment 2 Lennart Poettering 2016-02-10 16:58:35 EST
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 17:30:07 EST
(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 05:55:29 EST
THe mentioned fix is here:

https://github.com/systemd/systemd/pull/2576
Comment 5 Lennart Poettering 2016-02-11 11:03:16 EST
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 11:59:05 EST
(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 09:01:32 EST
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 04:36:02 EDT
(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 13:50:28 EDT
(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 15:33:40 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.