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

[M. J. Everitt]

On 16/12/16 14:33, Rich Freeman wrote:
> On Fri, Dec 16, 2016 at 9:04 AM, Kristian Fiskerstrand <k_f@g.o> wrote:
>> On 12/16/2016 02:57 PM, Ciaran McCreesh wrote:
>>> On Fri, 16 Dec 2016 13:25:14 +0100
>>> Thomas Deutschmann <whissi@g.o> wrote:
>>>
>>> Perhaps it's time to realise that security bugs aren't that
>>> interesting, and that random data loss bugs and just plain missing
>>> features can be far more impactful in practice than some obscure
>>> security issue. All treating security bugs specially does is play into
>>> the "look at me, I'm important so you should pay me money or I'll put
>>> out another press release" drama certain consulting companies have set
>>> up. Broken code is broken whether or not the bug has been given a cute
>>> name and logo.
>>>
>> Exactly, a security vulnerability originally being an info leak or a low
>> probability risk that turns out to a denial of service on a stable
>> system due to lack of proper stabilization is a good argument for the
>> way things are today.
>>
> We already have different risk tiers for security issues depending on impact:
> https://www.gentoo.org/support/security/vulnerability-treatment-policy.html
>
> That is why I suggested sending out the notice once the fix is
> available, or at the expiration of the target delay.  For a
> trivial-class issue that would mean that a notice would only be sent
> out without a fix if it took over 40 days to resolve the problem.
>
> GLSAs are also marked with their severity/etc, so admins can use this
> information to make an informed decision about the risks of deploying
> an update out of cycle, or waiting for their normal testing cycle.
>
> Now, if we don't think that security is that important, then fine,
> let's at least update the security policy to make it clear to our
> users that we just treat remote network-only root code execution
> exploits the same as the latest vlc bump.  Then our users will know
> that they aren't actually protected and will take additional measures
> if they feel it is necessary.
>
> What I don't like is a public security policy that says we do xyz
> within n days, and in reality we don't really do that and we take a
> lot longer to do it.  That is giving users a false sense of security.
>
> Now, I get that upstream doesn't always release information on
> vulnerabilities, or even know about them.  Sure, if you're trying to
> run the NSA you probably shouldn't solely rely on your distro's
> security update mechanism.  People who REALLY care are going to
> subscribe to various services/etc to get intel on issues, or even do
> their own in-house research (if you're a major nation state).
>
> However, deploying fixes to known vulnerabilities just seems like a
> good practice.
>
> In any case, fixing the security policy to match reality costs
> nothing, and actually following it on the major archs shouldn't cost
> THAT much.
>
Picking a rather random post to chip in on, but here we go with my
thoughts...

How about once we identify a [triaged] security issue, it gets assigned
a GLSA there and then, and a templated email gets sent out to notify
users of the vulnerability and the priority assigned to it internally.
You could also tag a bugzilla reference, for users to track progress in
between identification and resolution. Then, you should be able to meet
your published policy by pushing out some information to users, and
especially sysadmins, so they are informed, and can choose for
themselves what actions they feel appropriate to take in the first
instance (eg. mitigation until resolution is found).

Then, post a 'FIXED' message referencing again the GLSA and bug ref. to
indicate the 'preferred' resolution, any appropriate package updates,
etc. once this has been tested/stabilised/etc. to allow for manpower
issues and anything else that could be considered 'beyond reasonable
control' from the Gentoo angle. Yes, so you get double the "spam", but
since security issues are relatively infrequent (vs. -dev bikeshedding,
etc) I don't honestly think that the burden of early vs. late
notification against extra email messages to be kept informed would be a
problem for most people appropriately concerned.