Gentoo Archives: gentoo-project

From: Rich Freeman <rich0@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] RFC: Making GLSAs useful for security
Date: Fri, 16 Dec 2016 14:33:54
Message-Id: CAGfcS_nyhAXEnu1yveXTK07fXV3Uydxyb3aeMATL0Bv3MdysGw@mail.gmail.com
In Reply to: Re: [gentoo-project] RFC: Making GLSAs useful for security by Kristian Fiskerstrand
1 On Fri, Dec 16, 2016 at 9:04 AM, Kristian Fiskerstrand <k_f@g.o> wrote:
2 > On 12/16/2016 02:57 PM, Ciaran McCreesh wrote:
3 >> On Fri, 16 Dec 2016 13:25:14 +0100
4 >> Thomas Deutschmann <whissi@g.o> wrote:
5 >>
6 >> Perhaps it's time to realise that security bugs aren't that
7 >> interesting, and that random data loss bugs and just plain missing
8 >> features can be far more impactful in practice than some obscure
9 >> security issue. All treating security bugs specially does is play into
10 >> the "look at me, I'm important so you should pay me money or I'll put
11 >> out another press release" drama certain consulting companies have set
12 >> up. Broken code is broken whether or not the bug has been given a cute
13 >> name and logo.
14 >>
15 >
16 > Exactly, a security vulnerability originally being an info leak or a low
17 > probability risk that turns out to a denial of service on a stable
18 > system due to lack of proper stabilization is a good argument for the
19 > way things are today.
20 >
21
22 We already have different risk tiers for security issues depending on impact:
23 https://www.gentoo.org/support/security/vulnerability-treatment-policy.html
24
25 That is why I suggested sending out the notice once the fix is
26 available, or at the expiration of the target delay. For a
27 trivial-class issue that would mean that a notice would only be sent
28 out without a fix if it took over 40 days to resolve the problem.
29
30 GLSAs are also marked with their severity/etc, so admins can use this
31 information to make an informed decision about the risks of deploying
32 an update out of cycle, or waiting for their normal testing cycle.
33
34 Now, if we don't think that security is that important, then fine,
35 let's at least update the security policy to make it clear to our
36 users that we just treat remote network-only root code execution
37 exploits the same as the latest vlc bump. Then our users will know
38 that they aren't actually protected and will take additional measures
39 if they feel it is necessary.
40
41 What I don't like is a public security policy that says we do xyz
42 within n days, and in reality we don't really do that and we take a
43 lot longer to do it. That is giving users a false sense of security.
44
45 Now, I get that upstream doesn't always release information on
46 vulnerabilities, or even know about them. Sure, if you're trying to
47 run the NSA you probably shouldn't solely rely on your distro's
48 security update mechanism. People who REALLY care are going to
49 subscribe to various services/etc to get intel on issues, or even do
50 their own in-house research (if you're a major nation state).
51
52 However, deploying fixes to known vulnerabilities just seems like a
53 good practice.
54
55 In any case, fixing the security policy to match reality costs
56 nothing, and actually following it on the major archs shouldn't cost
57 THAT much.
58
59 --
60 Rich

Replies

Subject Author
Re: [gentoo-project] RFC: Making GLSAs useful for security Kristian Fiskerstrand <k_f@g.o>
Re: [gentoo-project] RFC: Making GLSAs useful for security "M. J. Everitt" <m.j.everitt@×××.org>