Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: security@g.o
Subject: [gentoo-dev] [RFC] Beyond GLSAs: improving Gentoo Security user experience
Date: Sun, 21 Feb 2021 19:51:06
1 Hello, everyone.
3 TL;DR: I think we should work towards delivering a complete list of
4 vulnerable packages and ability to rebuild on that (not only these that
5 traditionally involved GLSAs), and possibly also information
6 on vulnerabilities that are not fixed reasonably quickly.
9 Background
10 ==========
12 The Gentoo Security process right now seems to be focused on developers.
13 We get Security bugs and CC package maintainers, we bump packages
14 and fast stabilize if necessary, we clean vulnerable versions up.
15 The process is good but in my opinion it's often missing the last step
16 -- actually delivering the fixes to our users.
18 Of course, it is a strong recommendation that people should keep their
19 system up-to-date by frequently running deep @world upgrades. However, I
20 think we all realize that not all people do that. In fact, our own Infra
21 doesn't do that and I have to say that right now our own servers are
22 probably running dozens of vulnerable packages.
24 While we could argue that people shouldn't do that (and we've been doing
25 this for years now), so far we haven't managed any great success at it.
26 Not to mention all the corner cases where you either can't upgrade or
27 you're simply silently forced by Portage to stay on an older version. So
28 it's time to explore the alternatives.
30 A quick grep shows that around 20% of Security bugs are getting GLSAs
31 ('glsa+' vs 'noglsa' whiteboard). This means that in roughly 80% cases
32 GLSA-based infrastructure (e.g. glsa-check) can't reliably inform users
33 of vulnerable packages and/or trigger upgrades.
35 The other side of the problem is that the GLSA process seems to be
36 rather focused on fixed vulnerabilities. However, we do not seem to
37 release GLSAs before a fixed version is available, even if there is
38 no fix in sight and there is a suggested mitigation (that we can't apply
39 ourselves).
42 The problems
43 ============
45 All this considered, I'd like to formulate two problems with the current
46 process:
48 1. Users are not explicitly informed and not provided with explicit
49 upgrade mechanism for vulnerabilities that are not considered GLSA-
50 worthy.
52 2. Users are not informed of important vulnerabilities that do not have
53 a proper fix at hand.
56 Potential solutions for Problem 1.
57 ==================================
59 I think the problem should be considered in two parts: the developer
60 input part and the delivery part.
62 As for the delivery part, one option would be to reuse the GLSA format.
63 Loosen the specification a little, and start publishing GLSAs without
64 specific details, possibly just some short summary and package matchers.
65 However, this would result in the GLSA repository growing significantly
66 -- not sure if we consider this a problem.
68 An alternative I can think of would be to use a flat file for this. This
69 is e.g. what NetBSD does (it keeps the verbose advisories and full list
70 of vulnerabilities separate). In fact, I suppose we could roughly use
71 package.mask-alike format to avoid inventing new formats.
73 As for the input part, I think we should try to avoid imposing much
74 additional work on Security team members. Ideally, we'd be able to make
75 this a 'one click' solution reusing the existing data (i.e. Security
76 bugs). However, I don't think this is entirely possible right now.
78 Something like having GLSAMaker pre-fill a template based on 'Package
79 list' field of a Security bug could be a good start. Alternatively, we
80 could look into doing the reverse -- giving all involved developers
81 minimal access to GLSAMaker, and having it initially file Security bugs
82 based on structured input.
85 Potential solutions to Problem 2.
86 =================================
88 Here I don't think we need much of a technical solution. Rather,
89 I think that Security team should be able to release GLSAs in these
90 cases to inform users of the situation.
94 ========
96 WDYT?