[gentoo-dev] RFC: Pre-GLEP: Security Project

[gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 600 bytes --]

A draft of a Pre-GLEP for the Security project is available for reading
at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security

The GLEP follows a line of GLEPs for special projects that have
tree-wide access in order to ensure proper accountability (c.f GLEP 48
for QA and still non-produced GLEP for ComRel (I've started working on
this and will be presenting this one later as current ComRel Lead))

Comments, patches, threats, etc welcome

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

Hi Kristian,

On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote:
> A draft of a Pre-GLEP for the Security project is available for reading
> at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security
> 
> The GLEP follows a line of GLEPs for special projects that have
> tree-wide access in order to ensure proper accountability (c.f GLEP 48
> for QA and still non-produced GLEP for ComRel (I've started working on
> this and will be presenting this one later as current ComRel Lead))
> 
> Comments, patches, threats, etc welcome

First of all, thank you for this Pre-GLEP, since we really need some
public and established policy for the Security project.

1. From this proposal it looks like the Security Project Lead
obtains a lot of power and a lot of responsibility, maybe too much
for a single person to handle.

While the Deputy may be assigned, this still gives all power to
single hands. Maybe it will be better to establish something like
the Security Project Council (SPC)? E.g. three project members may
be elected to this SPC, so that all serious decisions will require
some team agreement from at least 2 SPC members. This way the
Deputy will not be needed as well.

2. "If a vulnerability is unlikely to be fixed by upstream or the
package's maintainer it might require a package mask." — I'd like
to see this expanded to more detail, because it is possible to mask
for removal and to simply mask without scheduled removal.

Sometimes an application is desirable even if it is vulnerable,
e.g. if there are no alternatives. Sometimes a vulnerability is
minor or affect a very rare use case. Sometimes users need a
specific software version for their workflow and they don't really
care about security — this affects many scientific packages being
used at isolated HPC setups.

My point is that users must be informed about security problem, but
they still should have a choice. So it should be either a rule
"mask without removal" or clear guidelines when to remove a
package and when to not.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 2832 bytes --]

On 03/11/2017 11:23 PM, Andrew Savchenko wrote:
> Hi Kristian,
> 
> On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote:
>> A draft of a Pre-GLEP for the Security project is available for reading
>> at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security
>>
>> The GLEP follows a line of GLEPs for special projects that have
>> tree-wide access in order to ensure proper accountability (c.f GLEP 48
>> for QA and still non-produced GLEP for ComRel (I've started working on
>> this and will be presenting this one later as current ComRel Lead))
>>
>> Comments, patches, threats, etc welcome
> 
> First of all, thank you for this Pre-GLEP, since we really need some
> public and established policy for the Security project.
> 
> 1. From this proposal it looks like the Security Project Lead
> obtains a lot of power and a lot of responsibility, maybe too much
> for a single person to handle.
> 
> While the Deputy may be assigned, this still gives all power to
> single hands. Maybe it will be better to establish something like
> the Security Project Council (SPC)? E.g. three project members may
> be elected to this SPC, so that all serious decisions will require
> some team agreement from at least 2 SPC members. This way the
> Deputy will not be needed as well.
> 

The thinking here is that the project lead is the responsible party. Any
ambiguity can still be escalated to the Gentoo Council, but someone
needs to be responsible from the side of the Gentoo Security Project.

> 2. "If a vulnerability is unlikely to be fixed by upstream or the
> package's maintainer it might require a package mask." — I'd like
> to see this expanded to more detail, because it is possible to mask
> for removal and to simply mask without scheduled removal.
> 
> Sometimes an application is desirable even if it is vulnerable,
> e.g. if there are no alternatives. Sometimes a vulnerability is
> minor or affect a very rare use case. Sometimes users need a
> specific software version for their workflow and they don't really
> care about security — this affects many scientific packages being
> used at isolated HPC setups.
> 
> My point is that users must be informed about security problem, but
> they still should have a choice. So it should be either a rule
> "mask without removal" or clear guidelines when to remove a
> package and when to not.

At some point, of a package does not belong in the main tree due to
security vulnerabilities, they can still be kept in an overlay by a
respective project without it impacting other users. I'm not convinced
that impacts the overall user experience of other Gentoo users.


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Rich Freeman]

On Sat, Mar 11, 2017 at 6:54 PM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> On 03/11/2017 11:23 PM, Andrew Savchenko wrote:
>>
>> My point is that users must be informed about security problem, but
>> they still should have a choice. So it should be either a rule
>> "mask without removal" or clear guidelines when to remove a
>> package and when to not.
>
> At some point, of a package does not belong in the main tree due to
> security vulnerabilities, they can still be kept in an overlay by a
> respective project without it impacting other users. I'm not convinced
> that impacts the overall user experience of other Gentoo users.
>

Is there any reason that this can't be left to maintainer discretion?
The package is masked and clearly advertises its security issue.  The
user can make an informed choice.  Do we really need to force the
issue further?  What is the benefit to Gentoo in doing so?

-- 
Rich

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Walter Dnes]

- Typo...
Additional Security Project bugzilla notes
* The Security Project is except (should that read "exempt"?)



- An intermediate level before masking might be issuing a warning if
  some simple, specific remediation measure can protect against a
  vulnerability.  E.g. forcing cups to only listen to 127.0.0.1 or :1

- If you want to absolutely ensure that people are warned of a severe,
  but remediable vulnerability, is it acceptable to "break the build"
  by requiring a new local USE flag for the ebuild?  I'm thinking of
  something like "glep_0001234", "glep_0001235", "glep_0001236", etc,
  and have the ebuild die if the flag is not set, and print out a URL
  for a security problem.  This could be abstracted to make.conf with
  a new variable...

  GLEP="0001234 0001235 0001236 etc etc"

  This would probably be the last stage before masking.  It would
deliberately break the build, and require the user/admin to take manual
action (add the flag for the GLEP) before proceeding further.  This is
a heavy-handed method, but masking is more final.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Alexis Ballier]

On Sat, 11 Mar 2017 21:50:51 +0100
Kristian Fiskerstrand <k_f@gentoo.org> wrote:

> A draft of a Pre-GLEP for the Security project is available for
> reading at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security
> 
> The GLEP follows a line of GLEPs for special projects that have
> tree-wide access in order to ensure proper accountability (c.f GLEP 48
> for QA and still non-produced GLEP for ComRel (I've started working on
> this and will be presenting this one later as current ComRel Lead))
> 
> Comments, patches, threats, etc welcome
> 

Most of it seems more appropriate for a project page to me and up to
the sec. team, so I'll comment on the global parts only.

The only global part I see is the "Security package version/revision
bumps and package masks". This one would benefit from a proper
definition of the rules here: If severity is X then inactive is defined
to be Y days. After that, sec. team can fix themselves. It should also
be the same for masking: If severity is X and no fix is known after Y
days/months then sec. team should mask it (but not last rite it, this
should still be maintainer/treecleaners).

I think the delay should be clearly stated in the bug with something
like: Please keep in mind that since this is a remote code execution
vulnerability, security team will take action if nothing happens within
one week. If you have tools filling the severity fields then a proper
definition allows to automate this too.

My point here is to avoid having all the responsibility falling under
the lead but focus more on getting things done and educating fellow
developers: Lower delays for more serious bugs will make people
understand and prioritize better the issues at hand and their
implications.


Also, it'd be nice to have something more formal for sec. cleanup:
"After 30 days a sec. issue has been fixed, sec. team is free to
cleanup old vulnerable versions.". I've seen too much pings by sec.
team members on old bugs for this and they could have spent the same
amount of time simply doing it instead.

Alexis.

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Alexis Ballier]

On Sun, 12 Mar 2017 09:14:09 +0100
Alexis Ballier <aballier@gentoo.org> wrote:

> My point here is to avoid having all the responsibility falling under
> the lead

In other words: If you want to avoid having bugs inactive for too long,
don't introduce a bus factor of 1 through the project lead :)

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]

On 2017.03.11 20:50, Kristian Fiskerstrand wrote:
> A draft of a Pre-GLEP for the Security project is available for
> reading
> at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security
> 
> The GLEP follows a line of GLEPs for special projects that have
> tree-wide access in order to ensure proper accountability (c.f GLEP 48
> for QA and still non-produced GLEP for ComRel (I've started working on
> this and will be presenting this one later as current ComRel Lead))
> 
> Comments, patches, threats, etc welcome
> 
> -- 
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> 
> 

Kristian,

First of all, thank you. We have needed something like this for several 
projects, for some time.

A few odds and ends.

Why do Security Project members need to be ebuild devs?
Non ebuild developers can contribute by producing GLSAs, 
for example. 

Who manages the Security Project (from outside).  It appears from
the draft GLEP, nobody.  That means that the project could become 
moribund and nobody would notice.  Its not like Gentoo enforces 
or even checks for leadership elections. That's an anual event 
anyway, so its not a measure of a projects continued well being. 

Compare the Security Project to council, that have a monthly 
showing of project health. 

Projects tend to be left alone. Gentoo has several projects that 
appear to be unmanaged but cannot be permitted to die out. 
This is one. Who takes the Security Projects pulse and how?

A periodic automated message to -dev that all Security Project
members "reply to list" is both public and mimnimally invasive.
Its no more than 'roll call'.

Now the hard one, who does what when there is no pulse from 
the Security Project?

This isn't really a Security Project issue. If its ever needed, the 
Security Project isn't active. It affects other projects too, like
comrel, QA and others. Perhaps there is a common solution
to taking a proqcts pulse and reacting when there is none.  

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1656 bytes --]

On 03/12/2017 07:11 PM, Roy Bamford wrote:


> 
> Why do Security Project members need to be ebuild devs?
> Non ebuild developers can contribute by producing GLSAs, 
> for example. 

Where is that requirement stated?

> 
> Who manages the Security Project (from outside).  It appears from
> the draft GLEP, nobody.  That means that the project could become 
> moribund and nobody would notice.  Its not like Gentoo enforces 
> or even checks for leadership elections. That's an anual event 
> anyway, so its not a measure of a projects continued well being. 
> 

Imposing too much bureaucracy and reporting might not be worthwhile, the
security project's work is relatively easy to monitor in bugzilla
activity and GLSA publication to begin with, less so for auditing, but
that has always been specific to available resources.

> 
> This isn't really a Security Project issue. If its ever needed, the 
> Security Project isn't active. It affects other projects too, like
> comrel, QA and others. Perhaps there is a common solution
> to taking a proqcts pulse and reacting when there is none.  
> 

Talking with the lead of respective projects should be a good start
without need for specific procedures. One could imagine participation
from various special projects in council meetings or just email
exchanges, but it'd likely just end up with a bunch of "nothing new from
the western front" that can more easily just be updated informally
anyways if anyone is concerned.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 2435 bytes --]

On 03/12/2017 03:55 AM, Rich Freeman wrote:
> On Sat, Mar 11, 2017 at 6:54 PM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>> On 03/11/2017 11:23 PM, Andrew Savchenko wrote:
>>>
>>> My point is that users must be informed about security problem, but
>>> they still should have a choice. So it should be either a rule
>>> "mask without removal" or clear guidelines when to remove a
>>> package and when to not.
>>
>> At some point, of a package does not belong in the main tree due to
>> security vulnerabilities, they can still be kept in an overlay by a
>> respective project without it impacting other users. I'm not convinced
>> that impacts the overall user experience of other Gentoo users.
>>
> 
> Is there any reason that this can't be left to maintainer discretion?
> The package is masked and clearly advertises its security issue.  The
> user can make an informed choice.  Do we really need to force the
> issue further?  What is the benefit to Gentoo in doing so?
> 

In most cases lack of maintainer participation is likely the issue to
begin with. The primary issue with a package mask of this nature is that
it is more permanent than temporary in nature. To what extent would
other package maintainers need to take it into consideration e.g wrt
depgraph breakages (say this is a lower slotted version or last version
that supports a specific arch).

Granted that isn't much of an issue from the security point of view, but
goes more over on QA - the primary reason it isn't explicit in the draft
GLEP is that specific rules are difficult to write to cover all
situations and as such needs either a lot of preparation to write or
will cause issues down the line. The accountability aspects of things is
therefore more important than the rules themselves.

Quite frankly I thought I left enough of maintainer discretion when
stating:
* The Security Project does not want to override the maintainer's
autonomy, but
  if inactive might be required to fix a security vulnerability by means of
  version bump or application of a patch in a revision bump.
* If a vulnerability is unlikely to be fixed by upstream or the
package's maintainer
  it might require a package mask. Such mask should never break the
stable dependency tree.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1182 bytes --]

On 03/12/2017 07:19 AM, Walter Dnes wrote:
> - Typo...
> Additional Security Project bugzilla notes
> * The Security Project is except (should that read "exempt"?)

Thanks, fixed

> 
> 
> 
> - An intermediate level before masking might be issuing a warning if
>   some simple, specific remediation measure can protect against a
>   vulnerability.  E.g. forcing cups to only listen to 127.0.0.1 or :1

Mitigations like these are mentioned in the GLSA

> 
> - If you want to absolutely ensure that people are warned of a severe,
>   but remediable vulnerability, is it acceptable to "break the build"
>   by requiring a new local USE flag for the ebuild?  I'm thinking of
>   something like "glep_0001234", "glep_0001235", "glep_0001236", etc,
>   and have the ebuild die if the flag is not set, and print out a URL
>   for a security problem.  This could be abstracted to make.conf with
>   a new variable...
> 
>   GLEP="0001234 0001235 0001236 etc etc"

Sounds like a lot of complexity for limited value.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Rich Freeman]

On Sun, Mar 12, 2017 at 2:45 PM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>
> In most cases lack of maintainer participation is likely the issue to
> begin with. The primary issue with a package mask of this nature is that
> it is more permanent than temporary in nature. To what extent would
> other package maintainers need to take it into consideration e.g wrt
> depgraph breakages (say this is a lower slotted version or last version
> that supports a specific arch).
>
> Granted that isn't much of an issue from the security point of view, but
> goes more over on QA.

Sure, and if a package like this becomes a blocker then that would be
a reason to remove it.

The fact that it has a security issue is actually irrelevant to that decision.

-- 
Rich

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 3007 bytes --]

On 03/12/2017 09:14 AM, Alexis Ballier wrote:
> Most of it seems more appropriate for a project page to me and up to
> the sec. team, so I'll comment on the global parts only.
> 
> The only global part I see is the "Security package version/revision
> bumps and package masks". This one would benefit from a proper
> definition of the rules here: If severity is X then inactive is defined
> to be Y days. After that, sec. team can fix themselves. It should also
> be the same for masking: If severity is X and no fix is known after Y
> days/months then sec. team should mask it (but not last rite it, this
> should still be maintainer/treecleaners).

The severity levels and timelines are already defined in the referenced
vulnerability treatment policy. We might be able to incorporate this
suggestion by stronger reference to that for timeline, but in the end
that should be the internal policy anyways. In general I would prefer
the GLSA to be more higher level as we know things are going to need to
be updated from time to time on these matters.

> 
> I think the delay should be clearly stated in the bug with something
> like: Please keep in mind that since this is a remote code execution
> vulnerability, security team will take action if nothing happens within
> one week. If you have tools filling the severity fields then a proper
> definition allows to automate this too.
> 
> My point here is to avoid having all the responsibility falling under
> the lead but focus more on getting things done and educating fellow
> developers: Lower delays for more serious bugs will make people
> understand and prioritize better the issues at hand and their
> implications.

The lead sets policies and is responsible for keeping vulnerability
treatment policy and other documentation up to date c.f Documentation of
process

The Project shall have procedures in place to document its process and
regularly update the documentation including the Vulnerability Treatment
Policies[3].

^^ which was intended to cover some of these concerns

> 
> 
> Also, it'd be nice to have something more formal for sec. cleanup:
> "After 30 days a sec. issue has been fixed, sec. team is free to
> cleanup old vulnerable versions.". I've seen too much pings by sec.
> team members on old bugs for this and they could have spent the same
> amount of time simply doing it instead.

This presumes all security members are gentoo developers with tree
access and can do it themselves, but I'm not convinced cleanups are
vital enough for security to interact as it requires quite a bit of work
for an unfamiliar package to know which files to remove in files/ for
specific versions and/or other package-specific quirks. The package
maintainers really should be able to handle this or hand off the package
to someone else.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Alexis Ballier]

On Sun, 12 Mar 2017 19:59:11 +0100
Kristian Fiskerstrand <k_f@gentoo.org> wrote:

> On 03/12/2017 09:14 AM, Alexis Ballier wrote:
> > Most of it seems more appropriate for a project page to me and up to
> > the sec. team, so I'll comment on the global parts only.
> > 
> > The only global part I see is the "Security package version/revision
> > bumps and package masks". This one would benefit from a proper
> > definition of the rules here: If severity is X then inactive is
> > defined to be Y days. After that, sec. team can fix themselves. It
> > should also be the same for masking: If severity is X and no fix is
> > known after Y days/months then sec. team should mask it (but not
> > last rite it, this should still be maintainer/treecleaners).  
> 
> The severity levels and timelines are already defined in the
> referenced vulnerability treatment policy. We might be able to
> incorporate this suggestion by stronger reference to that for
> timeline, but in the end that should be the internal policy anyways.


To me, this is the only thing that is *not* internal here.

You have a target delay X. What happens after X expires ? After 2X ?
10X ? When is it right for sec. team to intervene ? When is it right
for sec. team to intervene after maintainer has asked for a delay ? When
is it right for sec. team to intervene against maintainer wishes ?

I'm pretty sure you have a good idea of when sec. team should act, and
you're right in the sense that severity analysis does not belong to the
GLEP, but something referencing your treatment policy and explicitly
stating in the GLEP that (any member of) sec. team is allowed to take
action after some multiple (possibly one) of the target delay would be
more clear and avoid entirely having the lead to take a decision every
time.

I'm insisting here for various reasons:
- It is preferable to have a clear resolution procedure, known in
  advance, instead of something at someone's discretion that happens
  to be brought up every time some other one is not happy.
- Sometimes sec. masking will be controversial (nethack maybe?), having
  the lead take all the hate is not fair either.
- I would definitely prefer saying about Gentoo: "We do not ship
  anything that has had a CVE reported for more than a month" than "We
  do our best to keep your system safe".


Also, please keep in mind that for most people A4/A3/B3/B4/etc. are
paper sizes :) (so that restating the delay in sec bugs is not wasted
electrons)


[...]
> > Also, it'd be nice to have something more formal for sec. cleanup:
> > "After 30 days a sec. issue has been fixed, sec. team is free to
> > cleanup old vulnerable versions.". I've seen too much pings by sec.
> > team members on old bugs for this and they could have spent the same
> > amount of time simply doing it instead.  
> 
> This presumes all security members are gentoo developers with tree
> access and can do it themselves, but I'm not convinced cleanups are
> vital enough for security to interact as it requires quite a bit of
> work for an unfamiliar package to know which files to remove in
> files/ for specific versions and/or other package-specific quirks.
> The package maintainers really should be able to handle this or hand
> off the package to someone else.

Well, I'm not saying the maintainer should not nor that sec. team must
do it themselves, I'm just saying that sec. team can. There are
complex cases but the vast majority of security cleanups are no
brainers that anyone who has passed the quizzes can do.

Alexis.

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1496 bytes --]

On 03/12/2017 11:05 PM, Alexis Ballier wrote:
>> The severity levels and timelines are already defined in the
>> referenced vulnerability treatment policy. We might be able to
>> incorporate this suggestion by stronger reference to that for
>> timeline, but in the end that should be the internal policy anyways.
> 
> To me, this is the only thing that is *not* internal here.
> 
> You have a target delay X. What happens after X expires ? After 2X ?
> 10X ? When is it right for sec. team to intervene ? When is it right
> for sec. team to intervene after maintainer has asked for a delay ? When
> is it right for sec. team to intervene against maintainer wishes ?
> 
> I'm pretty sure you have a good idea of when sec. team should act, and
> you're right in the sense that severity analysis does not belong to the
> GLEP, but something referencing your treatment policy and explicitly
> stating in the GLEP that (any member of) sec. team is allowed to take
> action after some multiple (possibly one) of the target delay would be
> more clear and avoid entirely having the lead to take a decision every
> time.

makes sense, will try to write up some more info on this in GLEP, while
still referencing the vulnerability treatment policy for the actual
information as that needs to be possible to update from time to time.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1302 bytes --]

On 03/11/2017 11:23 PM, Andrew Savchenko wrote:
> While the Deputy may be assigned, this still gives all power to
> single hands. Maybe it will be better to establish something like
> the Security Project Council (SPC)? E.g. three project members may
> be elected to this SPC, so that all serious decisions will require
> some team agreement from at least 2 SPC members. This way the
> Deputy will not be needed as well.

Something like this has been discussed. I personally don't like the
approach too much given that it adds a certain degree of bureaucracy and
can remove responsibility. An important part of the GLEP is that the
project lead is responsible to the council for the changes that is made.
Having possibility to overrule that by members would mean that the lead
is not able to control the action, and as such, can't be responsible for
it. If the members disagree with the lead they can call for re-election
as per GLEP:39 already.

As discussed in another sub-thread, however, will try to incorporate
more of the procedure in the vulnerability treatment policy etc into the
GLEP such that procedures are more in focus.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

On Sun, Mar 12, 2017 at 02:54:22PM -0400, Rich Freeman wrote:
> On Sun, Mar 12, 2017 at 2:45 PM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> >
> > In most cases lack of maintainer participation is likely the issue to
> > begin with. The primary issue with a package mask of this nature is that
> > it is more permanent than temporary in nature. To what extent would
> > other package maintainers need to take it into consideration e.g wrt
> > depgraph breakages (say this is a lower slotted version or last version
> > that supports a specific arch).
> >
> > Granted that isn't much of an issue from the security point of view, but
> > goes more over on QA.
> 
> Sure, and if a package like this becomes a blocker then that would be
> a reason to remove it.
> 
> The fact that it has a security issue is actually irrelevant to that decision.

I disagree with this argument. A security issue *is* a problem,
especially if we are masking the package because of the security issue.

imo to increase the quality of the tree, packages with known, unfixable
security issues belong in overlays, not in the main tree.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[gentoo-dev] Re: RFC: Pre-GLEP: Security Project

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 5127 bytes --]

Hi,

I am quoting <https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security>:

> == Abstract ==
> This GLEP outlines the purpose, responsibilities and abilities of the
> Gentoo Security Project.
>
> == Motivation ==
> This GLEP aims to document the processes of the Security Project and
> enpowering the project to operate on a wide scale across the Gentoo
> tree, within the structure provided by this GLEP.

I disagree with that. It looks like this GLEP was formed on base of
GLEP:48 [1] but I think this is wrong (like I would withdraw GLEP:48 now
that I read it).

For example, the purpose and the process of a project shouldn't be part
of any GLEP. These are project internal details and every project is
free to change its process without a new GLEP approval.

Also, for me the draft goes completely in the wrong direction.

I would get rid of the entire "Security Project Lead" and "Joining the
Project" paragraph:

Gentoo security project is a project like any other Gentoo project: The
team should decide in regular meetings how they want to do things. The
team is encouraged to elect a lead each year like any other project is
encouraged to do. In case of tied votes, the vote of the current lead
will be counting twice to get a decision but this isn't special so we
don't need to write it down for the security project.

Because project lead may change each year, the absolute majority of the
whole team must accept new members. Otherwise, the new project lead
would be responsible for people who maybe in the project just because
the previous lead liked them but he/she maybe don't trust them. But
again, this is something the project would decide and shouldn't be
handled in a GLEP.


The "Security package version/revision bumps and package masks" looks
relevant because it defines the "power" of the project:

> * The Security Project does not want to override the maintainer's
>   autonomy, but if inactive might be required to fix a security
>   vulnerability by means of version bump or application of a patch in
>   a revision bump.

I am not sure about this point. I am not aware of any GLEP/rule
disallowing devs to touch packages of any other devs. When I did my
quizzes I learned that you should have good reasons to do so and that
you are responsible for any breakage. In other words: Only do that after
you tried to contact the package maintainer (create a bug,
write an email, try to talk to the maintainer/project in IRC...) but did
not get a reply in time and always respect maintainer's coding
preferences (i.e. don't rewrite the whole ebuild because you would do
things differently when you just wanted to add a small patch fixing a
build issue).

In other words: Everyone is allowed to bump a package so we don't need
to write down that security project is allowed to do that as well.

It is different for QA project because QA members maybe rewrite a whole
ebuild and ignore maintainer's preferences for project goals.


> * If a vulnerability is unlikely to be fixed by upstream or the
>   package's maintainer it might require a package mask. Such mask
>   should never break the stable dependency tree.

From my understanding the intention of this point is to make clear that
security project members are allowed to remove an ebuild/package for
ARCH users.

I would get rid of the "such mask should never break stable dependency
tree" because this a general rule. However, sometimes this might be
required: Imagine an application (app-misc/awesome) which still depends
on dev-lang/openssl-0.9.8 or any other ancient version of a dev-lang/*
package. The application itself is fine and working but no one is
providing an update to work with newer dependencies.
Now the dependencies are EOL and a vulnerability was discovered. Because
everything else has already migrated to a newer version no one is
providing a patch. To get stable tree clean we would have to apply a
package.mask. This would break the stable dependency tree so we would
also need to take action against app-misc/awesome.

This is something we should write down so everyone knows that the
Gentoo security project has this power.


> * These actions, performed on behalf of the Security Project, should
>   only be used if the Project finds it is in the best interest of
>   users and fellow developers to have the issue addressed as soon as
>   possible. Such action needs to be approved by the Security Project
>   Lead (or if a Deputy is appointed; the Deputy)

This should be removed because this doesn't belong into a GLEP. That's
how the project internally works. And if the team decide to change
how it handle things this shouldn't require a new GLEP.


"Subscription to security lists and acting on behalf of Gentoo",
"Auditing and public reporting of issues in the name of Gentoo",
"Embargoed lists" and "CVE Numbering Authority (CNA) status" don't
belong into a GLEP. This is about the project's internal organization.


See also:
=========
[1] https://wiki.gentoo.org/wiki/GLEP:48


-- 
Regards,
Thomas


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1637 bytes --]

On 2017-03-12 00:54, Kristian Fiskerstrand wrote:
>> 1. From this proposal it looks like the Security Project Lead
>> obtains a lot of power and a lot of responsibility, maybe too much
>> for a single person to handle.
>>
>> While the Deputy may be assigned, this still gives all power to
>> single hands. Maybe it will be better to establish something like
>> the Security Project Council (SPC)? E.g. three project members may
>> be elected to this SPC, so that all serious decisions will require
>> some team agreement from at least 2 SPC members. This way the
>> Deputy will not be needed as well.
>>
> The thinking here is that the project lead is the responsible party. Any
> ambiguity can still be escalated to the Gentoo Council, but someone
> needs to be responsible from the side of the Gentoo Security Project.

I completely disagree with that.

The whole powerful lead/deputy thing is going in the wrong direction.

We don't need that. Security project is nothing special and doesn't need
a strong lead with such a power to rule the entire Gentoo project.

In general, every full member in the project should be equal. So I would
list them all as confidential contact for example. This would lower the
chance to compromise a member because an attacker wouldn't know who will
get contacted. If we would only have one contact (like the lead) this
would be a high-value target.
Because the security project has some inactive/dev away members the team
maybe want to select some main contacts instead. But this is up to the
team/project and doesn't belong in any GLEP.


-- 
Regards,
Thomas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1770 bytes --]

On 2017-03-12 23:53, Kristian Fiskerstrand wrote:
> On 03/11/2017 11:23 PM, Andrew Savchenko wrote:
>> While the Deputy may be assigned, this still gives all power to
>> single hands. Maybe it will be better to establish something like
>> the Security Project Council (SPC)? E.g. three project members may
>> be elected to this SPC, so that all serious decisions will require
>> some team agreement from at least 2 SPC members. This way the
>> Deputy will not be needed as well.
> 
> Something like this has been discussed. I personally don't like the
> approach too much given that it adds a certain degree of bureaucracy and
> can remove responsibility. An important part of the GLEP is that the
> project lead is responsible to the council for the changes that is made.
> Having possibility to overrule that by members would mean that the lead
> is not able to control the action, and as such, can't be responsible for
> it. If the members disagree with the lead they can call for re-election
> as per GLEP:39 already.

Looks like we are disagreeing about the role of a project lead.

The primary goal of any Gentoo project is to group people working
towards the same goal(s) in small, manageable groups. It shouldn't need
a lead in most cases to control the project members.

A lead is only needed if the team can't get a decision.

Saying that the team could call for re-election if they don't like
lead's decision is ridiculous from my view: Like said it isn't the lead
who controls the direction. It is the lead who should step down if
he/she doesn't feel comfortable with the team decision and no longer
wants to represent the project anymore because he/she disagree so much
with the team decision.


-- 
Regards,
Thomas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 947 bytes --]

On 2017-03-12 19:35, Kristian Fiskerstrand wrote:
>> Why do Security Project members need to be ebuild devs?
>> Non ebuild developers can contribute by producing GLSAs, 
>> for example.
>
> Where is that requirement stated?

I agree with Roy. That's also my reading of

>  * The applicant must have successfully completed the Gentoo Developer quiz.

I agree with that requirement for a full membership (nobody would share
not yet disclosed vulnerabilities with us if he/she can't be sure that
people who will get this information aren't part of the project. I.e.
people will assume that these people have agreed on the same things
which is part of the process).

My answer for people who aren't devs yet but want to help: Feel free to
help! There are so many ways to help/contribute. If your motivation is
just a badge your are wrong for the project.

However, this doesn't belong into a GLEP.


-- 
Regards,
Thomas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Rich Freeman]

On Mon, Mar 13, 2017 at 3:28 PM, Thomas Deutschmann <whissi@gentoo.org> wrote:
>
> Looks like we are disagreeing about the role of a project lead.
>
> The primary goal of any Gentoo project is to group people working
> towards the same goal(s) in small, manageable groups. It shouldn't need
> a lead in most cases to control the project members.
>
> A lead is only needed if the team can't get a decision.
>

That isn't the only reason a team might need a lead.  A lead might
also be necessary if the larger distro doesn't trust the members of
the team to make their own decisions.

Now that I have everybody's attention, let's take a step back before
diving back into that.

IMO there are broadly two ways to look at the security project.

1.  It is a normal project.

If security is a normal project then IMO we don't need any GLEPs.  It
elects its own leads if it wishes, like any other project.  The
purpose of the lead is what Thomas suggested, which is to facilitate,
break ties, and so on.

The project could write its own policies, just as any other project
can.  They wouldn't need special approval, but they'd still be subject
to the general discretion all projects/devs have and nobody would
really be subject to those policies except voluntarily.

In such a model the security project would touch packages just like
any other developer/project would.  It would nudge maintainers, and if
there was no response it could act unilaterally.  I believe that is
standing policy across the board - if a maintainer doesn't reply
anybody can touch packages already.

If there were some dispute, security could escalate the situation to
QA.  In a sense you could almost view security as a subproject of QA.
Since QA is a special project it can override maintainers and the
escalation process for that is already established.

2.  It is a special project.

If security is a special project, then we do need a GLEP to outline
what its powers are and how it operates because it doesn't just fall
under GLEP 39 like everything else.

In such a model security might act without involving QA, within
whatever general guidelines are set in the GLEP.

In this model the lead MAY have the purpose I got at: the lead isn't
just about facilitating the wishes of the project members, but it is
also about ensuring that the project conforms to the GLEP and respects
the wishes of the larger distro.  When more powers are given, more is
expected in return.  The lead must be accountable in some way to the
rest of the distro, which is why it would be appropriate to have them
confirmed by the council (and I'd probably steal the other boilerplate
from the QA GLEP about the Council appointing interim leads and so
on).


And this is why I think you are talking past each other.  Kristian is
thinking in terms of security being a special project, and Thomas is
thinking in terms of security being a normal project.  Both are making
completely reasonable suggestions in those contexts.

Personally I'm on the fence on this one, which was why I am not
entirely convinced we need a GLEP for this.  If security can operate
well as a normal project then IMO it should do so.  Then we don't need
any special powers, and we don't need any special treatment of its
lead.  There doesn't need to be any special sort of accountability.
IMO the normal model is simpler, and I don't want to see a world where
every little Gentoo project has to have the Council confirming its
lead.

The two areas that I see as possibly pushing security towards being a
special project are:
1.  Masking or otherwise directly touching packages without waiting
for the maintainer if the timeline passes.
2.  Being able to represent Gentoo on special security mailing lists
that have tight distribution.  (If somebody betrays this trust Gentoo
could find itself cut off from all such lists, so Gentoo should use
care here.)

I'll finally note that there is also a possible compromise.  We might
make security somewhat special, but decide that its powers aren't that
important and so let it self-govern without forced Council
interaction.  Even so we should probably create some avenue for appeal
so that the next time an argument comes up over whether long-term
masks vs overlays are the right solution people feel like they had
input into the decision.

Apologies if I did not correctly interpret anybody else's stance here;
there is always peril in trying to guess what somebody else is
thinking.  Ultimately I think the question is whether security is more
like python, or more like QA.

-- 
Rich

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[William L. Thomson Jr.]

[-- Attachment #1.1: Type: text/plain, Size: 1459 bytes --]

On Monday, March 13, 2017 4:33:54 PM EDT Rich Freeman wrote:
> On Mon, Mar 13, 2017 at 3:28 PM, Thomas Deutschmann <whissi@gentoo.org> wrote:
> > Looks like we are disagreeing about the role of a project lead.
> > 
> > The primary goal of any Gentoo project is to group people working
> > towards the same goal(s) in small, manageable groups. It shouldn't need
> > a lead in most cases to control the project members.
> > 
> > A lead is only needed if the team can't get a decision.
> 
> That isn't the only reason a team might need a lead.  A lead might
> also be necessary if the larger distro doesn't trust the members of
> the team to make their own decisions.

There is also the idea that Team Leads work with other Team Leads to resolve conflicts and/
or for integration. Technical conflicts, but could be other. Rather than individual team 
members hashing it out with each other voicing individual opinions rather than the 
collective opinion of the team funneled through the leader. Intended more for organization 
than control.

Like when I interact with a client, usually easiest to have a single point of contact. Rather 
than have every employee interacting with me directly. Essentially the contact becomes the 
client "lead".

In a Utopian world all Team Leads may meet with the council as part of a bigger picture. 
Everything coming together as one. Part of the idea behind the GLEP I suggested about 
reporting.

-- 
William L. Thomson Jr.


[-- Attachment #1.2: Type: text/html, Size: 5159 bytes --]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 978 bytes --]

On 03/13/2017 08:38 PM, Thomas Deutschmann wrote:
> On 2017-03-12 19:35, Kristian Fiskerstrand wrote:
>>> Why do Security Project members need to be ebuild devs?
>>> Non ebuild developers can contribute by producing GLSAs, 
>>> for example.
>>
>> Where is that requirement stated?
> 
> I agree with Roy. That's also my reading of
> 
>>  * The applicant must have successfully completed the Gentoo Developer quiz.
> 
> I agree with that requirement for a full membership (nobody would share
> not yet disclosed vulnerabilities with us if he/she can't be sure that

now I'm even more lost. Gentoo Developer quiz does not imply ebuild
repository access, we have current developers in the project without
tree access and they are doing an outstanding job, so depending on the
definition of "full membership" ....


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 3640 bytes --]

On 2017-03-13 21:33, Rich Freeman wrote:
> [...]
> 
> And this is why I think you are talking past each other.  Kristian is
> thinking in terms of security being a special project, and Thomas is
> thinking in terms of security being a normal project.  Both are making
> completely reasonable suggestions in those contexts.

Thank you for this good summary. Really appreciated. From my view, you
got all the stances.


> The two areas that I see as possibly pushing security towards being a
> special project are:
> 1.  Masking or otherwise directly touching packages without waiting
> for the maintainer if the timeline passes.

Like said, clarifying the p.mask thing would be nice. Is it required?
No, I don't think so. At the moment I still trust in the Gentoo project
to find a solution in case we would have a situation like described [1].
But maybe I am too new and missed a fight ;-)


> 2.  Being able to represent Gentoo on special security mailing lists
> that have tight distribution.  (If somebody betrays this trust Gentoo
> could find itself cut off from all such lists, so Gentoo should use
> care here.)

People trust people, not titles. While it is important to have a
security contact, and we have security contacts listed [2], people will
contact a dev they know/trust using established channels and don't check
for current project lead. And this is a good thing.

Yes, anyone with @gentoo.org address could do harm to the Gentoo
project. You cannot prevent situations like that. If someone decides to
do something stupid in the name of Gentoo he/she can do.
All we can do is to clearly distance ourselves from the person and
making clear using our channels that this is not Gentoo's position and
that we have taken actions (any project may decide to kick someone; go
to ComRel; go to Council... our process to deal with situations like
that is well defined).

When I am saying the security project isn't special I am saying this
about the need of special privileges in the Gentoo world. Joining the
project is special. At least I am not aware that there are other Gentoo
projects where you have to pass an additional recruitment process
(besides infra and QA project). This is needed because project members
will get in touch with confidential information. People sharing
information with Gentoo security project trust in Gentoo to handle that
as expected.

If someone manages to join Gentoo security project, become a full member
and then starts to abuse gained knowledge (i.e. share/use confidential
information), this would damages the trust in Gentoo for years. I.e.
external sources would stop sharing information with Gentoo.

But this is nothing a project lead can prevent. Also, if the project
lead would be the only one responsible, what should happen in that case?
Should the lead who failed because he/she trusted the wrong person also
leave the Gentoo project and we are done?


> I'll finally note that there is also a possible compromise.  We might
> make security somewhat special, but decide that its powers aren't that
> important and so let it self-govern without forced Council
> interaction.  Even so we should probably create some avenue for appeal
> so that the next time an argument comes up over whether long-term
> masks vs overlays are the right solution people feel like they had
> input into the decision.

Sounds good for me.


See also:
=========
[1]
https://archives.gentoo.org/gentoo-dev/message/46fdaade8901c2bda3197aaf0e7b5d87

[2] https://gentoo.org/support/security/#contact


-- 
Regards,
Thomas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 514 bytes --]

On 2017-03-13 22:47, Kristian Fiskerstrand wrote:
> now I'm even more lost. Gentoo Developer quiz does not imply ebuild
> repository access, we have current developers in the project without
> tree access and they are doing an outstanding job, so depending on the
> definition of "full membership" ....

Mh, I missed <https://bugs.gentoo.org/show_bug.cgi?id=599322>: Staffer
quiz was renamed to Developer quiz in December 2016.

And yes, they are doing an outstanding job.


-- 
Regards,
Thomas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Yury German]

> On Mar 12, 2017, at 4:14 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> 
> 
> Also, it'd be nice to have something more formal for sec. cleanup:
> "After 30 days a sec. issue has been fixed, sec. team is free to
> cleanup old vulnerable versions.". I've seen too much pings by sec.
> team members on old bugs for this and they could have spent the same
> amount of time simply doing it instead.


Alexis, here is a problem that I have noticed over the years. Everyone is short on time, but if the developers do not step in (and only some) and clean up the packages then we might as well make this another job for Security team as everyone will just leave it to security.

Security looks at every security bug, and needs to do a lot of things behind the scenes. GLSA writing, look for CVE’s if not there, assign them to bugs in the CVE system used for GLSA’s. If no CVE’s exist communicate with upstream to see if it was requested, if not requested request it on their behalf and work with MITRE in getting it assigned. When you multiply that time over the 100+ security bugs at any time. Cleanup is not a 5 second thing as for me typing three characters to have that bug be submitted with that comment. 

The maintainer also knows the package, dependencies, other bugs filed, etc. Removing things for your packages might be simple, but it is not the same across all packages and that is the reason we ask the Maintainers to take an active step in cleaning up.

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Rich Freeman]

On Tue, Mar 14, 2017 at 7:55 PM, Yury German <blueknight@gentoo.org> wrote:
>
>
> The maintainer also knows the package, dependencies, other bugs filed, etc. Removing things for your
> packages might be simple, but it is not the same across all packages and that is the reason we ask the
> Maintainers to take an active step in cleaning up.

I agree.

The security team should be empowered to do the cleanup, but I think
their first priority should be to administering the overall process.
Anything maintainers can do to move it along is probably going to make
the process more efficient.

The reality is that most of the "work" in terms of commits/etc in
security work is really done by maintainers and arch teams.  The main
role of the security team is to ensure that it is all happening, so
they're going to spend a lot of time herding along everybody else.
They can always chip in with other things but if they don't do the
administrative overhead nobody else will.

-- 
Rich

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Yury German]

[-- Attachment #1.1: Type: text/plain, Size: 1540 bytes --]



On 3/13/17 3:10 PM, Thomas Deutschmann wrote:

> I completely disagree with that.
> 
> The whole powerful lead/deputy thing is going in the wrong direction.
> 
> We don't need that. Security project is nothing special and doesn't need
> a strong lead with such a power to rule the entire Gentoo project.
> 
> In general, every full member in the project should be equal. So I would
> list them all as confidential contact for example. This would lower the
> chance to compromise a member because an attacker wouldn't know who will
> get contacted. If we would only have one contact (like the lead) this
> would be a high-value target.

That is not possible (every full member as a confidential contact). This
is not something that is allowed by the upstream early notification
teams. We have tried using a mailing list and only very few would accept
that.

Also this is important for point of contacts as well. Once the
confidential contacts receive the email they put in to bugzilla and make
it security bug at that point everyone sees it.

> Because the security project has some inactive/dev away members the team
> maybe want to select some main contacts instead. But this is up to the
> team/project and doesn't belong in any GLEP.

That is the whole point of elections, if the lead is away then the
deputy takes over the role. If the deputy can  not do the job for some
reason then they can be changed to another deputy.  There is no problems
with that, the deputy role being a non-elected role.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Yury German]

[-- Attachment #1.1: Type: text/plain, Size: 1215 bytes --]

On 3/13/17 3:28 PM, Thomas Deutschmann wrote:

> A lead is only needed if the team can't get a decision.
> 
> Saying that the team could call for re-election if they don't like
> lead's decision is ridiculous from my view: Like said it isn't the lead
> who controls the direction. It is the lead who should step down if
> he/she doesn't feel comfortable with the team decision and no longer
> wants to represent the project anymore because he/she disagree so much
> with the team decision.

The security team has always worked in a process where the direction of
the team (with the leads) has always been decided as a team. Based on
reading the GLEP it is the goal of it to assign responsibility and not
to take control away from the other team members.

We have always discussed and voted on things in full disclosure. I see
nothing changing from the way we do things, and nothing is changing from
the way it is, projects have leads. People vote on project leads, the
security team has had and voted on project leads for a long time before.
There were two before, Alex and Tobias. Making it one or two is a
decision that can easily be discussed. Making it 15 leads just does not
work.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Yury German]

[-- Attachment #1.1: Type: text/plain, Size: 3105 bytes --]

Rick a very good message (and well thought out).

On 3/13/17 4:33 PM, Rich Freeman wrote:
> On Mon, Mar 13, 2017 at 3:28 PM, Thomas Deutschmann <whissi@gentoo.org> wrote:
> 
> The two areas that I see as possibly pushing security towards being a
> special project are:
> 1.  Masking or otherwise directly touching packages without waiting
> for the maintainer if the timeline passes.

Security team does not like doing this since we do not know the internal
workings of packages. But sometimes it is very much needed, remember
"heartblead?". The notification came to our points of contact (Alex
(a3li) and Tobias (keytoaster)), a private security bug was filed with
normal rating since the release was within our time-lines. Then in a few
hours the security team decided to release it. Well I remember all hell
breaking loose, and at that point direct involvement was involved.

For that reason for something like this I think we need a GLEP for. Not
to use every day, but lets call it "Emergency Power" that shall NOT be
abused.

> 2.  Being able to represent Gentoo on special security mailing lists
> that have tight distribution.  (If somebody betrays this trust Gentoo
> could find itself cut off from all such lists, so Gentoo should use
> care here.)

This is very important. Pre-Notification is on a case by case basis.
While we can define point of contacts, it is also important as a
reputation for Gentoo.

Lets say we want to become a CNA, just like  other distributions
(Debian, Red Hat, SUSE, Ubuntu) we need a person that would be
responsible for coordinating the information and the appropriate
paperwork and coordinate with Council or Foundation as needed. This can
not be a free for all.


> I'll finally note that there is also a possible compromise.  We might
> make security somewhat special, but decide that its powers aren't that
> important and so let it self-govern without forced Council
> interaction.  Even so we should probably create some avenue for appeal
> so that the next time an argument comes up over whether long-term
> masks vs overlays are the right solution people feel like they had
> input into the decision.

I think that it is not a power thing but more of a responsibility and
accountability that is being defined. There is nothing about Governance
by the council when I read the GLEP. The only thing is the confirmation
by the Council since they are Privy to a lot more information then all
the isolated Teams are, and can prevent problems ahead of time.

The GLEP is a draft also and I have already proposed some changes to
Kristian about some wording.

The idea here is that it is not someone taking away power, but just
continuing what we have been doing in Security for years and just
formulating some of the processes by the GLEP. We have always had leads
that received notifications, communicated on behalf of the team, settled
problems, etc.

We have always discussed and provided opinions on changes and no one was
dictated something before discussion (Unless Security Policy specific).


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Alexis Ballier]

On Tue, 14 Mar 2017 19:55:44 -0400
Yury German <blueknight@gentoo.org> wrote:

> > On Mar 12, 2017, at 4:14 AM, Alexis Ballier <aballier@gentoo.org>
> > wrote:
> > 
> > 
> > Also, it'd be nice to have something more formal for sec. cleanup:
> > "After 30 days a sec. issue has been fixed, sec. team is free to
> > cleanup old vulnerable versions.". I've seen too much pings by sec.
> > team members on old bugs for this and they could have spent the same
> > amount of time simply doing it instead.  
> 
> 
> Alexis, here is a problem that I have noticed over the years.
> Everyone is short on time, but if the developers do not step in (and
> only some) and clean up the packages then we might as well make this
> another job for Security team as everyone will just leave it to
> security.
> 
> Security looks at every security bug, and needs to do a lot of things
> behind the scenes. GLSA writing, look for CVE’s if not there, assign
> them to bugs in the CVE system used for GLSA’s. If no CVE’s exist
> communicate with upstream to see if it was requested, if not
> requested request it on their behalf and work with MITRE in getting
> it assigned. When you multiply that time over the 100+ security bugs
> at any time. Cleanup is not a 5 second thing as for me typing three
> characters to have that bug be submitted with that comment. 
> 
> The maintainer also knows the package, dependencies, other bugs
> filed, etc. Removing things for your packages might be simple, but it
> is not the same across all packages and that is the reason we ask the
> Maintainers to take an active step in cleaning up.


Agreed, but I was under the impression that sometimes sec. team was
waiting for cleanup to close a bug. If you've just done the analysis
that it is the only thing left, just do it and close the bug, instead
of pinging on the bug and re-do that analysis in a later pass. This
reduces context switches and makes everything more efficient :)

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1085 bytes --]

On 03/15/2017 08:12 AM, Alexis Ballier wrote:
> On Tue, 14 Mar 2017 19:55:44 -0400


> 
> 
> Agreed, but I was under the impression that sometimes sec. team was
> waiting for cleanup to close a bug. If you've just done the analysis
> that it is the only thing left, just do it and close the bug, instead
> of pinging on the bug and re-do that analysis in a later pass. This
> reduces context switches and makes everything more efficient :)
> 


Indeed, although it should be noted that the amount of context switches
is reduced by using whiteboards to tag status along with version
information in summary, which is why it is important they follow
security team policies for security bugs.

In particular the whiteboard status allows for effective filtering when
creating work-lists to reduce context switching (so if you're a
maintainer starting a stablereq, feel free to update whiteboard from
ebuild to stable!)

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]