1 |
On Tue, Dec 4, 2018 at 4:05 PM Kristian Fiskerstrand <k_f@g.o> wrote: |
2 |
|
3 |
> On 12/4/18 9:55 PM, Kristian Fiskerstrand wrote: |
4 |
> |
5 |
> > security_project-structure.rst |
6 |
> > |
7 |
> > Abstract ======== |
8 |
> > |
9 |
> > This GLEP outlines the abilities and purpose of the Gentoo Security |
10 |
> > Project. |
11 |
> > |
12 |
> > Motivation ========== |
13 |
> > |
14 |
> > The Gentoo Security Project is the public liaison between Gentoo or |
15 |
> > external users and Gentoo developers in any security-related field. |
16 |
> > The project's mission is to ensure that each known threat in software |
17 |
> > packaged in the stable ebuild repository (stable tree) is fixed in a |
18 |
> > timely manner, thus ensuring that users in the stable version of |
19 |
> > Gentoo receive quality and secure software. |
20 |
> > |
21 |
> > After considerable events regarding security in Gentoo Linux, like |
22 |
> > SPARC[#SPARC_REMOV]_ and HPPA [#HPPA_REMOV]_ removal from the |
23 |
> > "supported" security architectures, it has become quite obvious that |
24 |
> > the current policy regarding "supported" and "not supported" |
25 |
> > architectures is not capable of address the most important security |
26 |
> > factor, which is to ensure that end-users are protected from |
27 |
> > malicious/vulnerable packages in the stable tree. |
28 |
> > |
29 |
> > This is so because the Gentoo Security Project does not have a proper |
30 |
> > control nor is empowered to ensure that packages inside the stable |
31 |
> > branch of Gentoo Linux official ebuild repository are secure and can |
32 |
> > be fixed in a timely manner. Especially if a threat is published or |
33 |
> > disclosed by the security groups in which Gentoo Security Project has |
34 |
> > participation. |
35 |
> > |
36 |
> > The current policy of having a "supported" list of architectures does |
37 |
> > not work directly towards the objective of the Security project, |
38 |
> > instead, it only allows the project to recognize some architectures |
39 |
> > as "not supported" and don't be obligated to release a GLSA for that |
40 |
> > specific architecture when an issue arises. |
41 |
> |
42 |
> |
43 |
> I personally don't agree with part of this section; security is |
44 |
> relative, and if it is stated to not be supported there are no security |
45 |
> assumptions. If anything the removal of these arches as security |
46 |
> supported demonstrates an active decisions not to support them, and |
47 |
> signals to users of these arches that they can't depend on security |
48 |
> information from Gentoo. Stable generally means a stable tree of |
49 |
> dependencies, without security assumptions, if this is e.g used in a |
50 |
> closed lab that likely doesn't impact much. |
51 |
> |
52 |
> So comments welcome |
53 |
> |
54 |
|
55 |
Really this seems to be the primary problem with the status quo. Users tend |
56 |
to select a keyword (typically arch, ~arch, or ** for a given architecture |
57 |
keyword.) The security team already publishes a list of arch keywords that |
58 |
received security support. So in theory, curious users can of course, go |
59 |
read the list and see if their keyword is there. |
60 |
|
61 |
The problem of course is that the keywords have names. We might map |
62 |
["arch", "~arch", "**"][0] to "stable", "testing", and "unknown state" and |
63 |
the issue is that when users hear terms like "the stable arm tree" there is |
64 |
an implicit "stable X tree is security supported." This is of course not |
65 |
true, and the security team already publishes a list of arches that receive |
66 |
security support at their project page. |
67 |
|
68 |
If we compare again to Debian (begin the hate!) they work in a similar way |
69 |
to this proposal. In order to offer a stable package repository, you must |
70 |
be security supported. This means that ports with less staffing don't have |
71 |
a stable repository, they only have -unstable or -testing. However, Debian |
72 |
employs significant automation to gate packages and only has to support |
73 |
binary packages their repository, not compilation. I wouldn't necessarily |
74 |
encourage adopting their model. One thing I enjoy is that Debian has a |
75 |
clear FAQ outlining how to get security support (It says run debian stable, |
76 |
in case you are curious) and so one benefit is that it becomes obvious that |
77 |
e.g. you cannot run a 'secure' sparc port, because there is no sparc stable |
78 |
tree on offer from Debian. |
79 |
|
80 |
We might emulate this by, for example, Implementing GLEP 72, shipping the |
81 |
data in the tree, and then offering some kind of new match in make.conf. |
82 |
For example we might say: "SECURITY_SUPPORT=stable" and ARCH="arm". Portage |
83 |
would then look up "arm" in arch.desc, see that there are no "stable" "arm" |
84 |
states available in the GLEP 72 compatible arches.desc and the fail to do |
85 |
anything. |
86 |
|
87 |
[0] I'm ignoring package.mask here, mostly because I debate its relevance |
88 |
to this conversation. I suspect most users understand that "things in pmask |
89 |
are not production ready" and thus its clearer to users that installing |
90 |
pmask'd packages brings added risk (security or otherwise.) |
91 |
|
92 |
|
93 |
> > |
94 |
> > |
95 |
> > Specification ============= |
96 |
> > |
97 |
> > The Security Project's purpose is to ensure users in the stable |
98 |
> > category of Gentoo are provided with applications that to the best of |
99 |
> > the knowledge of the Gentoo Developers are free of vulnerabilities. |
100 |
> > In order to achieve this purpose, the Security Project require |
101 |
> > certain abilities and responsibilities as outlined in this GLEP in |
102 |
> > order to ensure the best interests of all users. |
103 |
> > |
104 |
> > Security Project Lead |
105 |
> |
106 |
> Since the security project is moving into tree wide territory here, the |
107 |
> following used to contain a section similar to GLEP 48 on council |
108 |
> approval of leads, but that was removed in a later revision, so we |
109 |
> welcome comments on the topic. Comments welcome. |
110 |
> |
111 |
> > --------------------- |
112 |
> > |
113 |
> > * The Security Project is required to have at least one Security |
114 |
> > Project Lead. * The Security Project Lead is chosen at least yearly |
115 |
> > by private or public election among the members of the Security |
116 |
> > Project. * The Security Project Lead's term expires one year after |
117 |
> > the voting is concluded. If the time expires the current Project Lead |
118 |
> > retains the position until the security team can have another |
119 |
> > election. In the case of Lead's definitive absence, the Security |
120 |
> > Project must start the election process in a timely manner. * The |
121 |
> > Security Project Lead can choose one member as a Deputy in case of |
122 |
> > only one Lead. The Deputy has all of its powers directly delegated |
123 |
> > from the Security Project Lead and thus the Deputy's actions and |
124 |
> > decisions should be considered equal to those of the Security Project |
125 |
> > Lead. * The Deputy is directly responsible to the Security Project |
126 |
> > Lead and its actions reflects upon the Security Project Lead. |
127 |
> > |
128 |
> > Joining the Project ------------------- |
129 |
> |
130 |
> |
131 |
> For some reason, the following section on removal from the project |
132 |
> received significant interest and as such became quite specific. |
133 |
> |
134 |
|
135 |
I wish I had a better idea for how to run projects in Gentoo, but I suspect |
136 |
the lack of resources to develop sane leaders ends up leading to such |
137 |
sections :/ |
138 |
|
139 |
|
140 |
> |
141 |
> > Removal from Project -------------------- |
142 |
> No futher immediate comments, please see initial email |
143 |
> |
144 |
|
145 |
> EOF |
146 |
> |
147 |
> |
148 |
You attached some RST, so I'm just going to do what you did and paste a |
149 |
bunch in :) |
150 |
|
151 |
Gentoo Linux supports several architectures and as such, it is vital |
152 |
to ensure that each one of them is secure, especially those being used |
153 |
by end-users. Because of that, the Security Team needs to be able to |
154 |
remove an architecture from the "stable" category if all of the following |
155 |
criteria are met: |
156 |
|
157 |
* The architecture stabilization team is not capable to stabilize |
158 |
packages in a timely manner. |
159 |
* The stabilization of packages takes longer than usual because of |
160 |
a specific architecture. |
161 |
* The Security Team has informed the architecture team that they are |
162 |
downgrading the level of security of the "stable" version of Gentoo. |
163 |
* The Security Team has confirmed the lack of improvement after sending |
164 |
the information to the respective architecture team. |
165 |
* The Security Team has requested the removal of the architecture to |
166 |
the Council and presented a report which explains why the named |
167 |
architecture needs to be removed from the "stable" version of Gentoo. |
168 |
|
169 |
|
170 |
I'm eager to see a lot more tooling here about the state of architectures |
171 |
and stability. Everyone loves reporting, right? |
172 |
|
173 |
So for example Per Arch: |
174 |
|
175 |
- Number of Outstanding security bumps / stabilization(s). |
176 |
- Number of Late security bumps / stabilization(s). # A measure of, each |
177 |
GLSA that was 'late' because of this arch. |
178 |
|
179 |
These two metrics seem to conform to the key items in 'why Security team |
180 |
might downgrade an arch' and I'd love to see them on qa-reports.gentoo.org |
181 |
in a public fashion. I really think it sets a nice narrative for Security |
182 |
team (who should have lots of clear objective data to back up their |
183 |
decisions) and also empower arch teams to manage these key cross-team |
184 |
deliverables themselves. |
185 |
|
186 |
-A |
187 |
|
188 |
-- |
189 |
> Kristian Fiskerstrand |
190 |
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net |
191 |
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
192 |
> |
193 |
> |