Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item

[Thomas Deutschmann]

Hi,

TL;DR:

Given that William said in the meanwhile, he sees no future for 
opentmpfiles [1] and that nobody else, including me, is interested in 
stepping up, things have changed.

Please start with the normal last-rite process and please please please, 
rephrase the news item and do not tell world that opentmpfiles has been 
masked due to the reported vulnerability because this would be wrong.

----

The package was masked due to a miscommunication with the Gentoo 
Security project.

While it is true that the way opentmpfiles is currently implemented 
allows for certain races, from the security point of view, you always 
have to classify the vulnerability in context of your threat model 
because security depends on multiple layers (onion model).

First, we have to take tmpfiles.d specifications into account:

By default, opentmpfiles service is only reading from certain locations 
(for example /usr/lib/tmpfiles.d) – all of these locations are only 
writable for root user by default which makes it impossible for an 
attacker to create a controllable exploit.

Furthermore, tmpfiles.d settings are only supposed for creation, 
deletion and cleaning of volatile and temporary files. Any package which
will install tmpfiles.d settings which will create files in persistent 
locations should be treated like a bug in the package itself (for Gentoo
packagers for example we have keepdir [3] function).

Same is true for packages installing tmpfiles.d settings which will 
create volatile and temporary directories in user writable locations,
which is usually treated like a weak file permission vulnerability in 
the package, similar to world-writable PID files, config files, log
locations etc.

Despite all the outlined pre-requirements, an attacker would still need 
to convince the system administrator to restart a boot service which is
very uncommon and even OpenRC is warning against doing something like that.

opentmpfiles specifically starts before any other services, so a 
compromised daemon is not capable of injecting a malicious symlink 
before startup:

> $ /lib/rc/bin/rc-depend opentmpfiles-setup
> sysfs devfs udev udev-trigger hwclock modules fsck root localmount opentmpfiles-setup

Finally, in Gentoo Linux, like in many other distributions, from
security point of view, we assume certain preconditions like running
with "fs.protected_symlinks" and "fs.protected_hardlinks" enabled by
default since baselayout-2.7 [4] which largely mitigates symlink attacks.

(These sysctls don't affect CVE-2017-18925, but they do affect
the other reported opentmpfiles CVEs, and it's worth mentioning
them as examples of configuration we have to assume.)

Therefore, Gentoo's security project does not believe that it is 
required to mask this package in Gentoo Linux for security reasons 
because our classification from 2017 has not changed and we usually do 
not mask any package with flaws which cannot be exploited in default 
configuration and would require discouraged settings like disabled
fs.protected_symlink feature, or adjusting e.g. OpenRC's 
runlevels/configuration in an unsupported way.

Thank you.


See also:
=========
[1] 
https://archives.gentoo.org/gentoo-dev/message/bce91b9d37db0b1e0980eb923a8607c9

[2] 
https://www.gentoo.org/support/security/vulnerability-treatment-policy.html

[3] https://devmanual.gentoo.org/function-reference/install-functions/

[4] https://bugs.gentoo.org/704914


-- 
Regards,
Thomas Deutschmann / Gentoo Security Team
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5