Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
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") > 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
> > > > 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 dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
On Wed, Jul 14, 2021 at 12:04:34AM +0200, Andreas K. Huettel wrote: > > > 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). > > > 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
> 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). 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 dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
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
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
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 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
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
