NSS chroot protection

NSS chroot protection

[Florian Weimer]

In order to avoid security regressions, we disabled reloading of
/etc/nsswitch.conf after the chroot has changed.  We also went a step
further and disabled loading additional NSS modules based on the
*current* loaded configuration.

Apparently, that breaks a few chroot hacks that use incomplete chroots
for service confinement (rather than a complete operating system image).

Should we revert the second part and keep loading new service modules?

In a future glibc version, we could perhaps move files & dns into
libc.so.6, and reenable the load-inhibition feature for other modules
(that aren't files or dns).

Comments?

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

Re: NSS chroot protection

[Carlos O'Donell]

On 2/16/21 7:11 AM, Florian Weimer via Libc-alpha wrote:
> In order to avoid security regressions, we disabled reloading of
> /etc/nsswitch.conf after the chroot has changed.  We also went a step
> further and disabled loading additional NSS modules based on the
> *current* loaded configuration.
> 
> Apparently, that breaks a few chroot hacks that use incomplete chroots
> for service confinement (rather than a complete operating system image).

Just to be clear, it breaks a chroot-based framework that relied on
loading NSS modules from the chroot?

The current examples are:

* php-fpm with chroot failing to load chroot modules.
* openldap with -u -r fails in the chroot because it can't lookup users.

These cases are scenarios where the user created a matching chroot
and expected to be able to continue operating after the chroot call.

They used to work and now they don't.

Fixing them would require rewriting the chroot-based framework to
exec a helper process in the chroot. That is going to have a performance
impact and require time to setup correct.
 
> Should we revert the second part and keep loading new service modules?

I dislike reverting the fix. It is natural to create a boundary between
the configuration outside of the chroot and inside of the chroot.

May I suggest a more radical approach?

Load all the NSS service modules when the first modules is loaded,
and keep the the fix in place?

Avoids glibc upgrade issues if a module was never loaded.

It solves the problem of telling users to "preload" all the NSS modules
they might need (difficult to figure out) to avoid loading modules
they don't trust.

It has negative performance and RSS impact for any process that touches
NSS modules, but makes the semantics much clearer. As soon as you touch
one module, all modules are loaded, otherwise no modules are loaded.

> In a future glibc version, we could perhaps move files & dns into
> libc.so.6, and reenable the load-inhibition feature for other modules
> (that aren't files or dns).

It still worries me that we might load untrusted modules from a container
as with CVE-2019-14271.

-- 
Cheers,
Carlos.

Re: NSS chroot protection

[Stefan Liebler]

On 2/16/21 11:22 PM, Carlos O'Donell via Libc-alpha wrote:
> The current examples are:
> 
> * php-fpm with chroot failing to load chroot modules.
> * openldap with -u -r fails in the chroot because it can't lookup users.
> 

Just to add a further example:

* kata-containers loads the home-directory via getpwuid_r after pivot root:
https://github.com/kata-containers/kata-containers/blob/e830192fcab199dac9c7c2166182bd28adb797ce/src/agent/rustjail/src/container.rs#L655

Re: NSS chroot protection

[Florian Weimer]

* Carlos O'Donell:

>> Should we revert the second part and keep loading new service modules?
>
> I dislike reverting the fix. It is natural to create a boundary between
> the configuration outside of the chroot and inside of the chroot.
>
> May I suggest a more radical approach?
>
> Load all the NSS service modules when the first modules is loaded,
> and keep the the fix in place?

It will likely break systems like dpkg and RPM, where NSS library
dependencies can be temporarily inconsistent during updates.  As long as
those NSS modules fail to load, nothing bad will happen, but if there
are crashes due to ABI mismatches exposed by ELF constructors, we have
introduced upgrade failures.  (Such failures can be very difficult to
recover from on RPM systems.)  This wouldn't be something that I'd feel
comfortable backporting.  Lazy loading tends to paper over these
problems because updates typically only need files data for system
accounts.

Loading an NSS module which depends on libpthread may also not be safe
for all processes.  With the current lazy loading scheme, we avoid some
bugs related to late loading of libpthread because many processes only
need dns or files, which do not depend on libpthread.

Thanks,
Florian