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
OpenPGP_signature
Description: OpenPGP digital signature
