Mailing List Archive

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

On Sun, Jul 11, 2021 at 03:53:31PM +0200, Thomas Deutschmann wrote:
> 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.

Add this reference as well if you want, everyone upstream seems to agree
that opentmpfiles doesn't have a future.

https://github.com/OpenRC/opentmpfiles/issues/19

William

On Sun, 2021-07-11 at 15:53 +0200, Thomas Deutschmann wrote:
>
> 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).

Not crucial to your main point, but packages that use keepdir under
/var/cache (which is persistent) get prodded to use tmpfiles instead:

https://bugs.gentoo.org/692736

<snip>
> 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).
<snip>

I would like to respectfully point out that this makes

1) either the severity assignment of this bug by the Security project as B1 wrong (i.e. it should have been classified "harmless")

2) or the entire classification of severity levels according to the Security project pointless (i.e. you can't base any actions on them because a mystery onion needs to be taken into account).

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

--
Andreas K. H?ttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

On Wed, Jul 14, 2021 at 12:04:34AM +0200, Andreas K. Huettel wrote:
> <snip>
> > 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).
> <snip>
>
> I would like to respectfully point out that this makes
>
> 1) either the severity assignment of this bug by the Security project as B1 wrong (i.e. it should have been classified "harmless")
>

The Gentoo model is not perfect and should be overhauled. However, it
works for most things and sometimes bugs fall between the cracks.

The package shouldn't have been masked either based on a bug that was
purposely ignored for many years simply because they want to disband the
package now and found a "security reason" to add to the mask.

> 2) or the entire classification of severity levels according to the Security project pointless (i.e. you can't base any actions on them because a mystery onion needs to be taken into account).
>

I am not sure if this is sarcasm, but every bug must be considered
through the correct aperture. That is, based on your environment,
protections in place, defense in depth, and other buzzwords... hence the
onion analogy.

-Aaron

> >
> > 1) either the severity assignment of this bug by the Security project as B1 wrong (i.e. it should have been classified "harmless")
> >
>
> The Gentoo model is not perfect and should be overhauled. However, it
> works for most things and sometimes bugs fall between the cracks.
>
> The package shouldn't have been masked either based on a bug that was
> purposely ignored for many years simply because they want to disband the
> package now and found a "security reason" to add to the mask.

Well, over the last year or so every 2-3 months the (uninformed) discussion came up, "don't use openrc stages because you are automatically rooted". That leaves a rather bad impression of Gentoo, independent of whether it is true or not. If noone from sec team noticed the discussions...

> > 2) or the entire classification of severity levels according to the Security project pointless (i.e. you can't base any actions on them because a mystery onion needs to be taken into account).
> >
>
> I am not sure if this is sarcasm, but every bug must be considered
> through the correct aperture. That is, based on your environment,
> protections in place, defense in depth, and other buzzwords... hence the
> onion analogy.

It's not sarcasm. The point of the classification is to give clear rules (why else would you list, e.g., required response times on the vulnerability treatment page (no matter how illusory they are)).

If you don't take all factors into account when *making* the classification, then all gain you have from the classification is lost.



--
Andreas K. H?ttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

On Wed, Jul 14, 2021 at 10:49:34AM +0200, Andreas K. Huettel wrote:
> > >
> > > 1) either the severity assignment of this bug by the Security project as B1 wrong (i.e. it should have been classified "harmless")

<snip>

> Well, over the last year or so every 2-3 months the (uninformed) discussion came up, "don't use openrc stages because you are automatically rooted". That leaves a rather bad impression of Gentoo, independent of whether it is true or not. If noone from sec team noticed the discussions...

Absolutely, that would leave a bad impression. Where were these
discussions taking place?

>
> > > 2) or the entire classification of severity levels according to the Security project pointless (i.e. you can't base any actions on them because a mystery onion needs to be taken into account).
> > >
> >
> > I am not sure if this is sarcasm, but every bug must be considered
> > through the correct aperture. That is, based on your environment,
> > protections in place, defense in depth, and other buzzwords... hence the
> > onion analogy.
>
> It's not sarcasm. The point of the classification is to give clear rules (why else would you list, e.g., required response times on the vulnerability treatment page (no matter how illusory they are)).
>
> If you don't take all factors into account when *making* the classification, then all gain you have from the classification is lost.
>

Let me explain differently. Gentoo has a vulnerability rating system
that is indepedent of any other system. This system is used to classify
bugs from a distro perspective and common usage of various applications.

However, one cannot consider all possible attack vectors, impacts, and
configuration scenarios being used by our users. So, it is not lost...
we just can't possibly account for all the things.

Yes, the response times are utter crap and as I mentioned the Gentoo
system needs to be overhauled/adapted.

-Aaron