[gentoo-project] RFC: Making GLSAs useful for security

[Mart Raudsepp]

Hello,

Here's an idea for GLSA's I have always thought this should work like,
written down to hopefully find enough consensus and get done (probably
by security team, of which I am not part of). Lately hashed out in IRC
with bouncing it to Aaron Bauman.

tl;dr:
Don't delay release of GLSAs due to any stabling work; improve tooling
to allow differentiation of actionable (can upgrade to fixed version)
and informative GLSAs (e.g pending stabling for your arch) at a given
point of time.


Problem:

Even in a near-perfect world, where all security supported
architectures react in what we currently consider a timely manner, some
will delay once in a while. Even if just because the stabling for an
architecture is taken care of by people who can usually only spend time
on Gentoo over weekends. This can still mean ~5 days delays at times.
If we block GLSA release on that like we currently do, the majority of
our userbase doesn't get a notification, even if it's already stable
and fixable on their architecture (e.g, amd64), so they stay vulnerable
(unless they routinely keep stable system all upgraded) even though a
fix is readily available.
A less than a day notification is what we should thrive towards for the
common case, not settling with 3-5 days.



Solution proposal:

Push out a GLSA as soon as the relevant fix is available in the tree in
any form (usually when the security bug moves from [ebuild] to [stable]
state), so the fixed_in (unaffected) atoms have become known.



Keeping sysadmin sanity:

Start differentiating actionable vulnerabilities from those pending a
proper solution in our security tools, such as glsa-check.

Actionable vulnerabilities meaning like "can upgrade to a fix with my
ACCEPT_KEYWORDS" or "there will be no fix, this is last rited, get rid
of it".
Pending proper solution meaning "there is a known vulnerability you
might want to be aware of to disable the service, accept_keywords fixed
version locally, keep a close eye on as a fix becomes available soon,
or decide it doesn't affect the system as set up and used".

For example in case of glsa-check, there could be a new keyword identifier alongside "affected" and "all".
"all_vulnerabilities" or "known" or whatever could show all the vulnerabilities the system is affected by, even if a fix isn't readily available with your ACCEPT_KEYWORDS. Or "affected" could become that, and a new "actionable" or whatever one added for what "affected" is now. If we reach bikeshed on this naming, I conclude consensus on the generic idea ;)


Technical details:

To achieve this technically, I see two options for the tooling to figure out if a vulnerability affecting the system (based on GLSA affected atoms and what's installed on the system per VDB or equivalent):
1) Work on top of what's available in PORTDIR; or
2) Include the architecture keyword information inside the GLSA xml to not need PORTDIR availability.

1. would be an additional requirement for the tooling compared to status quo, as far as I know and so might not be desirable. For example binary package using systems or where the PORTDIR is not desired to be updated too often, unless a more often updated GLSA information tree shows the need.
2. is to sidestep that extra requirement, but would involve extra tools to automate the GLSA XML, which might pose other issues, e.g GPG signing; that in turn could be potentially workarounded by unsigned extra metadata files for the GLSAs.

This included information for (2) could be either a list of architectures where it's been stabled; list of architectures where stabling is pending or the fact that it is done for all applicable or stabling not applicable (last rite solutions). All this is just technical details if reliance of full PORTDIR is not desired. Alternatively it could work based on if it's available or not - if not, "affected" is equal to "all_vulnerabilities", so potentially listing things that can't be easily actioned; if available, might want to consider it also as if it wasn't, if the tree has not been updated recently enough.
Note that probably more things should show up under the "actionable" list for ~arch users compared to that architectures stable users - the tooling shouldn't limit itself with the systems architecture stable tree if it's an ~arch system. glsa-check is very useful for ~arch users as well, that can't always keep up with all upgrades and a fix is available for those usually even before the relevant architecture team has fulfilled the STABLEREQ.



Feel free to consider this an official proposal to the Gentoo Security team to consider amongst themselves in their upcoming meeting and with the wider community here if this kind of approach is suitable, and if yes, all the nitty-gritty details can be figured out in the usual bikeshed, followed by executive decision.



Best,
Mart Raudsepp
Making Gentoo Great Again