[gentoo-project] [pre-glep] Security Project Structure

[gentoo-project] [pre-glep] Security Project Structure

[Kristian Fiskerstrand]

[-- Attachment #1.1.1: Type: text/plain, Size: 334 bytes --]

I refer to discussions from Message-ID: <20181204012932.GL16376@monkey>

Attached is the current draft of a security project structure, I'll post
my own comments in a separate message

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

[-- Attachment #1.1.2: security_project-structure.rst --]
[-- Type: text/plain, Size: 12020 bytes --]

Abstract
========

This GLEP outlines the abilities and purpose of the Gentoo Security Project.

Motivation
==========

The Gentoo Security Project is the public liaison between Gentoo or external users
and Gentoo developers in any security-related field. The project's mission is
to ensure that each known threat in software packaged in the stable ebuild
repository (stable tree) is fixed in a timely manner, thus ensuring that
users in the stable version of Gentoo receive quality and secure software.

After considerable events regarding security in Gentoo Linux, like SPARC[#SPARC_REMOV]_
and HPPA [#HPPA_REMOV]_ removal from the  "supported" security architectures,
it has become quite obvious that the current policy regarding "supported" and
"not  supported" architectures is not capable of address the most important
security factor, which is to ensure that end-users are protected from
malicious/vulnerable packages in the stable tree.

This is so because the Gentoo Security Project does not have a proper control
nor is empowered to ensure that packages inside the stable branch of Gentoo
Linux official ebuild repository are secure and can be fixed in a timely manner.
Especially if a threat is published or disclosed by the security groups in which
Gentoo Security Project has participation.

The current policy of having a "supported" list of architectures does not work
directly towards the objective of the Security project, instead, it only allows
the project to recognize some architectures as "not supported" and don't be
obligated to release a GLSA for that specific architecture when an issue arises.


Specification
=============

The Security Project's purpose is to ensure users in the stable category of Gentoo
are provided with applications that to the best of the knowledge of the Gentoo
Developers are free of vulnerabilities. In order to achieve this purpose, the
Security Project require certain abilities and responsibilities as outlined in
this GLEP in order to ensure the best interests of all users.

Security Project Lead
---------------------

* The Security Project is required to have at least one Security Project Lead.
* The Security Project Lead is chosen at least yearly by private or public election
  among the members of the Security Project.
* The Security Project Lead's term expires one year after the voting is concluded. If
  the time expires the current Project Lead retains the position until the security
  team can have another election. In the case of Lead's definitive absence, the Security
  Project must start the election process in a timely manner.
* The Security Project Lead can choose one member as a Deputy in case of only one Lead.
  The Deputy has all of its powers directly delegated from the Security Project Lead
  and thus the Deputy's actions and decisions should be considered equal to those of
  the Security Project Lead. 
* The Deputy is directly responsible to the Security Project Lead and its actions
  reflects upon the Security Project Lead.

Joining the Project
-------------------

* All members wanting to join the Project need to be approved by the
  Security Project Lead or Leads (or if a Deputy is appointed; the Deputy).
* The applicant must demonstrate a thorough understanding of the duties
  he or she would like to perform. Specially those explained in the GLSA
  Coordinator Guide [#GLSA_COORD_GUIDE]_ and the Vulnerability Treatment Policy [#VULN_TREAT_POL]_.
* The applicant must complete the Padawan Process as outlined in the Security Project
  Wiki page.[#PADAWAN_PROCESS]_
* The applicant must have successfully completed the Gentoo Developer quiz.
* By accepting the applicant the Security Project Lead will accept the responsibility
  to direct them as part of the team and will be held responsible for any
  action the Project Member takes on behalf of the Security Project.
* The Security Project Lead may remove a member from the Security Project whenever
  reasonable.

Removal from Project
--------------------

The following guidelines should be followed to determine the continuity of a project
member who hasn't actively participated for a long period of time or has lost the
trust of the team lead(s) or members.

Any procedure and action should be discussed by the current active members to avoid
personal opinions at any point. If necessary there will be a votation to finally
decide if the member will be removed or not from the group, the only exception to
this rule is when Gentoo's public image is damaged by the member and an immediate
action is required, only the Team Lead can remove a member this way and even in
that case the member can appeal to a reconsideration by the whole Project.

If the member has not participated in more than 6 months in a consistent manner
in any of the tools that the Security Project uses for tracking purposes (e.g.
Bugzilla, GLSAMaker, mailing-lists, #gentoo-security, public or private repositories,
or any related tool) should be warned and in case necessary, his/her access to
privileged information should be revoked.

If a member has deliberately exposed private information, used his authority as
a team member to misguide information or publicly state information that requires
a confirmation without the Leaders knowledge and/or authorization, his/her access
to privileged information must be revoked.

Security role in architecture stabilization
-------------------------------------------

Gentoo Linux supports several architectures and as such, it is vital
to ensure that each one of them is secure, especially those being used
by end-users. Because of that, the Security Team needs to be able to
remove an architecture from the "stable" category if all of the following
criteria are met:

* The architecture stabilization team is not capable to stabilize
  packages in a timely manner.
* The stabilization of packages takes longer than usual because of
  a specific architecture.
* The Security Team has informed the architecture team that they are
  downgrading the level of security of the "stable" version of  Gentoo.
* The Security Team has confirmed the lack of improvement after sending
  the information to the respective architecture team.
* The Security Team has requested the removal of the architecture to
  the Council and presented a report which explains why the named
  architecture needs to be removed from the "stable" version of Gentoo.


Security package version/revision bumps and package masks
---------------------------------------------------------
* The Security Project does not want to override the maintainer's autonomy, but
  if the maintainer is not responsive, the Security Project 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.
* A package mask should only be applied if the security vulnerability identified
  warrants a GLSA c.f the Vulnerability Treatment Policy (VTP)[#VULN_TREAT_POL]_ and the elapsed time
  has exceeded three times the target delay specified in the VTP.
* 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)

Additional Security Project bugzilla notes
------------------------------------------
* The Security Project is exempt from the guideline of waiting 30 days for
  stabilization of a new package version.
* Bugs indicating a security vulnerability can be reassigned as a bug handled
  by the Gentoo Security Project.
* Bugs in the Gentoo Security category shall not be closed without the consent
  of a Gentoo Security Member.

Subscription to security lists and acting on behalf of Gentoo
-------------------------------------------------------------

Auditing and public reporting of issues in the name of Gentoo
-------------------------------------------------------------
Upstream reporting of expected security bugs should only be done using the
@gentoo.org email address if done by a member of the Security Auditing
Project or the issue has been privately reported and accepted as a security
vulnerability in accordance with the procedures set forth by the Security
Project (at the time of writing found in the GLSA Coordinator Guide[#GLSA_COORD_GUIDE]_section 2.4 Auditing).

Embargoed lists
---------------
Security Project Members should always keep information learned through access
to embargoed lists confidential. Access to other Gentoo Developers should only
be granted on a need to know basis, and Gentoo Developers gaining access to
such embargoed lists are required to keep the information confidential.

Requests to gain access to embargoed lists in the name of Gentoo should only
be done with the approval of the Security Project Lead (or if a Deputy is
appointed; the Deputy). The Security Project Lead is responsible for maintaining a list
of who has access to various embargoed lists and ensure proper updates in
access in accordance with developments of the Security Project both in terms
of active participation to ensure that the Security Project can act on the
information provided on these lists in a responsible manner and ensuring a
member no longer active in the Security Project has access in the name of
Gentoo.

CVE Numbering Authority (CNA) status
------------------------------------
The Security Project shall maintain tools and processes in a manner that is
compatible with becoming a CVE Numbering Authority[#CNA]_.

Documentation of processes
--------------------------
The Project shall have procedures in place to document its processes and
regularly update the documentation including the Vulnerability Treatment Policies[#VULN_TREAT_POL]_,
GLSA Coordinator Guide[#GLSA_COORD_GUIDE]_, Padawan Process [#PADAWAN_PROCESS]_.

Security supported architectures
--------------------------------
The Security Project is responsible of watch over all the ebuilds in the Gentoo
official ebuild repository marked as "stable". This means to look after known
vulnerable versions, and alert respective maintainers when a vulnerable package
needs to be fixed and stabilized. In order to achieve this task, the Security
Team will keep track of known CVEs, audit packages, and gather information
from external security groups to ensure that every ebuild marked as "stable"
is secure.

Rationale
=========
By delineating the roles, responsibilities and capabilities of the Gentoo Security
Project, we hope to secure the repository of Gentoo ebuilds as a whole. This
implies that with a good monitoring of the vulnerabilities and a good coordination
with the maintainers and arch teams, a user must have a system that can be called
"safe" by default, understanding "safe" as having each and every one of the packages
marked as "stable" as the most secure version available of them.

Backwards Compatibility
=======================

Not applicable for this GLEP.


References and Footnotes
========================

.. [#SPARC_REMOV] https://archives.gentoo.org/gentoo-announce/message/25ae524aa00fd0347346119da174951c 
.. [#HPPA_REMOV] https://archives.gentoo.org/gentoo-announce/message/196e45cde209d1ed25bd42e679739cf5
.. [#GLSA_COORD_GUIDE] https://wiki.gentoo.org/wiki/Project:Security/GLSA_Coordinator_Guide
.. [#VULN_TREAT_POL] https://www.gentoo.org/support/security/vulnerability-treatment-policy.html
.. [#PADAWAN_PROCESS] https://wiki.gentoo.org/wiki/Project:Security/Padawan_Process
.. [#CNA] https://cve.mitre.org/cve/cna.html


Copyright
=========

This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
Unported License.  To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/.


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

[gentoo-project] Re: [pre-glep] Security Project Structure

[Kristian Fiskerstrand]

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

On 12/4/18 9:55 PM, Kristian Fiskerstrand wrote:

> security_project-structure.rst
> 
> Abstract ========
> 
> This GLEP outlines the abilities and purpose of the Gentoo Security
> Project.
> 
> Motivation ==========
> 
> The Gentoo Security Project is the public liaison between Gentoo or
> external users and Gentoo developers in any security-related field.
> The project's mission is to ensure that each known threat in software
> packaged in the stable ebuild repository (stable tree) is fixed in a
> timely manner, thus ensuring that users in the stable version of
> Gentoo receive quality and secure software.
> 
> After considerable events regarding security in Gentoo Linux, like
> SPARC[#SPARC_REMOV]_ and HPPA [#HPPA_REMOV]_ removal from the
> "supported" security architectures, it has become quite obvious that
> the current policy regarding "supported" and "not  supported"
> architectures is not capable of address the most important security
> factor, which is to ensure that end-users are protected from 
> malicious/vulnerable packages in the stable tree.
> 
> This is so because the Gentoo Security Project does not have a proper
> control nor is empowered to ensure that packages inside the stable
> branch of Gentoo Linux official ebuild repository are secure and can
> be fixed in a timely manner. Especially if a threat is published or
> disclosed by the security groups in which Gentoo Security Project has
> participation.
> 
> The current policy of having a "supported" list of architectures does
> not work directly towards the objective of the Security project,
> instead, it only allows the project to recognize some architectures
> as "not supported" and don't be obligated to release a GLSA for that
> specific architecture when an issue arises.


I personally don't agree with part of this section; security is
relative, and if it is stated to not be supported there are no security
assumptions. If anything the removal of these arches as security
supported demonstrates an active decisions not to support them, and
signals to users of these arches that they can't depend on security
information from Gentoo. Stable generally means a stable tree of
dependencies, without security assumptions, if this is e.g used in a
closed lab that likely doesn't impact much.

So comments welcome

> 
> 
> Specification =============
> 
> The Security Project's purpose is to ensure users in the stable
> category of Gentoo are provided with applications that to the best of
> the knowledge of the Gentoo Developers are free of vulnerabilities.
> In order to achieve this purpose, the Security Project require
> certain abilities and responsibilities as outlined in this GLEP in
> order to ensure the best interests of all users.
> 
> Security Project Lead

Since the security project is moving into tree wide territory here, the
following used to contain a section similar to GLEP 48 on council
approval of leads, but that was removed in a later revision, so we
welcome comments on the topic. Comments welcome.

> ---------------------
> 
> * The Security Project is required to have at least one Security
> Project Lead. * The Security Project Lead is chosen at least yearly
> by private or public election among the members of the Security
> Project. * The Security Project Lead's term expires one year after
> the voting is concluded. If the time expires the current Project Lead
> retains the position until the security team can have another
> election. In the case of Lead's definitive absence, the Security 
> Project must start the election process in a timely manner. * The
> Security Project Lead can choose one member as a Deputy in case of
> only one Lead. The Deputy has all of its powers directly delegated
> from the Security Project Lead and thus the Deputy's actions and
> decisions should be considered equal to those of the Security Project
> Lead. * The Deputy is directly responsible to the Security Project
> Lead and its actions reflects upon the Security Project Lead.
> 
> Joining the Project -------------------


For some reason, the following section on removal from the project
received significant interest and as such became quite specific.

> Removal from Project --------------------
No futher immediate comments, please see initial email

EOF

-- 
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-project] Re: [pre-glep] Security Project Structure

[Michael Orlitzky]

On 12/4/18 4:05 PM, Kristian Fiskerstrand wrote:
> 
> I personally don't agree with part of this section; security is
> relative, and if it is stated to not be supported there are no security
> assumptions. If anything the removal of these arches as security
> supported demonstrates an active decisions not to support them, and
> signals to users of these arches that they can't depend on security
> information from Gentoo. Stable generally means a stable tree of
> dependencies, without security assumptions, if this is e.g used in a
> closed lab that likely doesn't impact much.
> 

This is technically correct, but: how many users even know what a 
security-supported arch is? I would guess zero, to a decimal point or 
two. Where would I encounter that information in my daily life?

If I pick up any software system that's run by professionals and that 
has a dedicated security team, my out-of-the-box assumption is that 
there aren't any known, glaring, and totally fixable security 
vulnerabilities being quietly handed to me.

Having a stable arch that isn't security-supported is a meta-fail... we 
have a system that fails open by giving people something that looks like 
it should be safe and then (when it bites them) saying "but you didn't 
read the fine print!" It should be the other way around: they should 
have to read the fine print before they can use those arches.

Re: [gentoo-project] Re: [pre-glep] Security Project Structure

[Kristian Fiskerstrand]

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

On 12/4/18 11:05 PM, Michael Orlitzky wrote:
> On 12/4/18 4:05 PM, Kristian Fiskerstrand wrote:
>>
>> I personally don't agree with part of this section; security is
>> relative, and if it is stated to not be supported there are no security
>> assumptions. If anything the removal of these arches as security
>> supported demonstrates an active decisions not to support them, and
>> signals to users of these arches that they can't depend on security
>> information from Gentoo. Stable generally means a stable tree of
>> dependencies, without security assumptions, if this is e.g used in a
>> closed lab that likely doesn't impact much.
>>
> 
> This is technically correct, but: how many users even know what a
> security-supported arch is? I would guess zero, to a decimal point or
> two. Where would I encounter that information in my daily life?
> 
> If I pick up any software system that's run by professionals and that
> has a dedicated security team, my out-of-the-box assumption is that
> there aren't any known, glaring, and totally fixable security
> vulnerabilities being quietly handed to me.
> 
> Having a stable arch that isn't security-supported is a meta-fail... we
> have a system that fails open by giving people something that looks like
> it should be safe and then (when it bites them) saying "but you didn't
> read the fine print!" It should be the other way around: they should
> have to read the fine print before they can use those arches.

Well, in terms of CVEs the documentation matters quite a bit, the
question isn't necessarily what any user would do ... but what a
reasonable user would do.. and a reasonable user would consider the
documented practices of a project.

-- 
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-project] Re: [pre-glep] Security Project Structure

[Michael Orlitzky]

On 12/4/18 5:17 PM, Kristian Fiskerstrand wrote:
> 
> Well, in terms of CVEs the documentation matters quite a bit, the
> question isn't necessarily what any user would do ... but what a
> reasonable user would do.. and a reasonable user would consider the
> documented practices of a project.
> 

There's too much crap to read. Sometimes you've just got to assume that 
a package marked "stable" on a popular distribution with a dedicated 
security team isn't going to have a 9-month-old well-known root exploit 
in the wild. That's perfectly reasonable to me.

Re: [gentoo-project] Re: [pre-glep] Security Project Structure

[Aaron Bauman]

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

On Tue, Dec 04, 2018 at 05:05:55PM -0500, Michael Orlitzky wrote:
> On 12/4/18 4:05 PM, Kristian Fiskerstrand wrote:
> > 
> > I personally don't agree with part of this section; security is
> > relative, and if it is stated to not be supported there are no security
> > assumptions. If anything the removal of these arches as security
> > supported demonstrates an active decisions not to support them, and
> > signals to users of these arches that they can't depend on security
> > information from Gentoo. Stable generally means a stable tree of
> > dependencies, without security assumptions, if this is e.g used in a
> > closed lab that likely doesn't impact much.
> > 
> 
> This is technically correct, but: how many users even know what a 
> security-supported arch is? I would guess zero, to a decimal point or 
> two. Where would I encounter that information in my daily life?
> 
> If I pick up any software system that's run by professionals and that 
> has a dedicated security team, my out-of-the-box assumption is that 
> there aren't any known, glaring, and totally fixable security 
> vulnerabilities being quietly handed to me.
> 
> Having a stable arch that isn't security-supported is a meta-fail... we 
> have a system that fails open by giving people something that looks like 
> it should be safe and then (when it bites them) saying "but you didn't 
> read the fine print!" It should be the other way around: they should 
> have to read the fine print before they can use those arches.
> 

+1

Wonderfully put and I couldn't agree more!

-- 
Cheers,
Aaron

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

Re: [gentoo-project] Re: [pre-glep] Security Project Structure

[Aaron Bauman]

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

On Tue, Dec 04, 2018 at 11:17:01PM +0100, Kristian Fiskerstrand wrote:
> Well, in terms of CVEs the documentation matters quite a bit, the
> question isn't necessarily what any user would do ... but what a
> reasonable user would do.. and a reasonable user would consider the
> documented practices of a project.
>

I suppose a "reasonable user" by your definition would also read and
track the CVE's to determine the security posture of their machine
on their own?

If so, we can disband the security team on that logic.

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




-- 
Cheers,
Aaron

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

Re: [gentoo-project] Re: [pre-glep] Security Project Structure

[Christopher Díaz Riveros]

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

El mar, 04-12-2018 a las 17:05 -0500, Michael Orlitzky escribió:
> On 12/4/18 4:05 PM, Kristian Fiskerstrand wrote:
> > 
> > I personally don't agree with part of this section; security is
> > relative, and if it is stated to not be supported there are no security
> > assumptions. If anything the removal of these arches as security
> > supported demonstrates an active decisions not to support them, and
> > signals to users of these arches that they can't depend on security
> > information from Gentoo. Stable generally means a stable tree of
> > dependencies, without security assumptions, if this is e.g used in a
> > closed lab that likely doesn't impact much.
> > 
> 
> This is technically correct, but: how many users even know what a 
> security-supported arch is? I would guess zero, to a decimal point or 
> two. Where would I encounter that information in my daily life?
> 
> If I pick up any software system that's run by professionals and that 
> has a dedicated security team, my out-of-the-box assumption is that 
> there aren't any known, glaring, and totally fixable security 
> vulnerabilities being quietly handed to me.
> 
> Having a stable arch that isn't security-supported is a meta-fail... we 
> have a system that fails open by giving people something that looks like 
> it should be safe and then (when it bites them) saying "but you didn't 
> read the fine print!" It should be the other way around: they should 
> have to read the fine print before they can use those arches.
> 

Or you could, as the GLEP states, try to give them the best set of packages (to
our knowledge) so that he/she does not need to read the fine print. That's one
of the main reasons I personally wanted to remove the "security supported list"
to a plain "stable == secure (to the best of our knowledge)", which should
accomplish the final goal: give the end-user something that is in both qa and
security the best possible output we can offer.

Best regards,
-- 
Christopher Díaz Riveros
Gentoo Linux Developer
GPG Fingerprint: E517 5ECB 8152 98E4 FEBC  2BAA 4DBB D10F 0FDD 2547

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

Re: [gentoo-project] Re: [pre-glep] Security Project Structure

[Virgil Dupras]

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

On Tue, 4 Dec 2018 17:05:55 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> 
> This is technically correct, but: how many users even know what a 
> security-supported arch is? I would guess zero, to a decimal point or 
> two. Where would I encounter that information in my daily life?
> 
> If I pick up any software system that's run by professionals and that 
> has a dedicated security team, my out-of-the-box assumption is that 
> there aren't any known, glaring, and totally fixable security 
> vulnerabilities being quietly handed to me.
> 
> Having a stable arch that isn't security-supported is a meta-fail... we 
> have a system that fails open by giving people something that looks like 
> it should be safe and then (when it bites them) saying "but you didn't 
> read the fine print!" It should be the other way around: they should 
> have to read the fine print before they can use those arches.
> 

I very much agree with this. If we end up deciding on keeping the
"supported arches" system, I would like to propose that we also add a
big red warning, on the download page of unsupported arches, that
states that this can't be considered secure and that links to our
Vulnerability Treatment Policy.

I don't have arm systems anymore, but for a while I did and at the
time, I wasn't aware at all of this situation. That's not fun and we
probably have many arm users right now who are unknowingly running
insecure systems.

Regards,
Virgil Dupras

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

Re: [gentoo-project] Re: [pre-glep] Security Project Structure

[M. J. Everitt]

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

On 04/12/18 22:30, Aaron Bauman wrote:
> On Tue, Dec 04, 2018 at 05:05:55PM -0500, Michael Orlitzky wrote:
>> On 12/4/18 4:05 PM, Kristian Fiskerstrand wrote:
>>> I personally don't agree with part of this section; security is
>>> relative, and if it is stated to not be supported there are no security
>>> assumptions. If anything the removal of these arches as security
>>> supported demonstrates an active decisions not to support them, and
>>> signals to users of these arches that they can't depend on security
>>> information from Gentoo. Stable generally means a stable tree of
>>> dependencies, without security assumptions, if this is e.g used in a
>>> closed lab that likely doesn't impact much.
>>>
>> This is technically correct, but: how many users even know what a 
>> security-supported arch is? I would guess zero, to a decimal point or 
>> two. Where would I encounter that information in my daily life?
>>
>> If I pick up any software system that's run by professionals and that 
>> has a dedicated security team, my out-of-the-box assumption is that 
>> there aren't any known, glaring, and totally fixable security 
>> vulnerabilities being quietly handed to me.
>>
>> Having a stable arch that isn't security-supported is a meta-fail... we 
>> have a system that fails open by giving people something that looks like 
>> it should be safe and then (when it bites them) saying "but you didn't 
>> read the fine print!" It should be the other way around: they should 
>> have to read the fine print before they can use those arches.
>>
> +1
>
> Wonderfully put and I couldn't agree more!
>
I accept that this is probably (to many) a ridiculous proposal, but is it
time to reconsider our arch profile definitions of "stable", "developer"
and "experimental" so that security policy is reflected in this? Something
like a "gold","silver", "bronze", "copper" system perhaps, with criteria
similar to the following:
- Gold - fully security audited, solid dependency tree
- Silver - best effort security audited, solid dependency tree
- Bronze - something akin to 'Developer' currently (dependency tracked but
not solid)
- Copper - entirely experimental

For me, as a concerned user, I'm prepared to take some risks on security,
as most of my systems are behind some form of firewall, and are mostly not
exposed to the wild internet. I would prefer that the packages I use are
"stable" ie. don't have known bugs, and their dependencies all check out
too. So I would qualify as a 'Silver' user.

I buy the argument that there are plenty of Gentoo users who
want/need/expect a 'Gold' service, and I think the security team are mostly
able to satisfy this requirement, even if arch teams are not (and I would
argue that it is simply the case that stabilisation can be 'passed' by any
maintainer for amd64/x86 arches that makes this feasible).

For arches with a depleted 'team' to do testing and stabilisation (and
indeed support) there should remain scope for that arch to be able to move
up or down (with council approval) easily and quickly, especially if there
should be a resurgence in interest from prospective devs/users. This would
automatically fulfil the manpower requirement, and the possibility of
reaching 'Gold' standard would become feasible.

I think there is merit also, in the distinction between 'dev' and 'exp'
profiles - and this is the reason I propose a 'Copper' status for arches
which really are truly experimental or problematic. Again, if there should
be an interested group willing to take on a change of status, this should
be encouraged and facilitated where possible.

I apologise in advance that this is somewhat tangential to the topic of
Security policy, but I feel that we shouldn't lose the basic meaning of
'stable' that we are using currently, without some form of tangible
replacement. Also, we shouldn't have users jumping through too many hoops,
to get a relatively known-good setup regardless of Arch.

</my 2 dollars>

veremitz/Michael.


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

Re: [gentoo-project] Re: [pre-glep] Security Project Structure

[Mikle Kolyada]

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


On 05.12.2018 6:46, Virgil Dupras wrote:
> On Tue, 4 Dec 2018 17:05:55 -0500
> Michael Orlitzky <mjo@gentoo.org> wrote:
>
>> This is technically correct, but: how many users even know what a 
>> security-supported arch is? I would guess zero, to a decimal point or 
>> two. Where would I encounter that information in my daily life?
>>
>> If I pick up any software system that's run by professionals and that 
>> has a dedicated security team, my out-of-the-box assumption is that 
>> there aren't any known, glaring, and totally fixable security 
>> vulnerabilities being quietly handed to me.
>>
>> Having a stable arch that isn't security-supported is a meta-fail... we 
>> have a system that fails open by giving people something that looks like 
>> it should be safe and then (when it bites them) saying "but you didn't 
>> read the fine print!" It should be the other way around: they should 
>> have to read the fine print before they can use those arches.
>>
> I very much agree with this. If we end up deciding on keeping the
> "supported arches" system, I would like to propose that we also add a
> big red warning, on the download page of unsupported arches, that
> states that this can't be considered secure and that links to our
> Vulnerability Treatment Policy.
>
> I don't have arm systems anymore, but for a while I did and at the
> time, I wasn't aware at all of this situation. That's not fun and we
> probably have many arm users right now who are unknowingly running
> insecure systems.
>
> Regards,
> Virgil Dupras


The "stable" definition within the security project is ridiculous and
has to be clarified.

Stable == "once stable arches are stabilised we can send a GLSA". It
does not mean

that so-called "security unstable" arches do not get stable updates.




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

Re: [gentoo-project] Re: [pre-glep] Security Project Structure

[Alec Warner]

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

On Tue, Dec 4, 2018 at 4:05 PM Kristian Fiskerstrand <k_f@gentoo.org> wrote:

> On 12/4/18 9:55 PM, Kristian Fiskerstrand wrote:
>
> > security_project-structure.rst
> >
> > Abstract ========
> >
> > This GLEP outlines the abilities and purpose of the Gentoo Security
> > Project.
> >
> > Motivation ==========
> >
> > The Gentoo Security Project is the public liaison between Gentoo or
> > external users and Gentoo developers in any security-related field.
> > The project's mission is to ensure that each known threat in software
> > packaged in the stable ebuild repository (stable tree) is fixed in a
> > timely manner, thus ensuring that users in the stable version of
> > Gentoo receive quality and secure software.
> >
> > After considerable events regarding security in Gentoo Linux, like
> > SPARC[#SPARC_REMOV]_ and HPPA [#HPPA_REMOV]_ removal from the
> > "supported" security architectures, it has become quite obvious that
> > the current policy regarding "supported" and "not  supported"
> > architectures is not capable of address the most important security
> > factor, which is to ensure that end-users are protected from
> > malicious/vulnerable packages in the stable tree.
> >
> > This is so because the Gentoo Security Project does not have a proper
> > control nor is empowered to ensure that packages inside the stable
> > branch of Gentoo Linux official ebuild repository are secure and can
> > be fixed in a timely manner. Especially if a threat is published or
> > disclosed by the security groups in which Gentoo Security Project has
> > participation.
> >
> > The current policy of having a "supported" list of architectures does
> > not work directly towards the objective of the Security project,
> > instead, it only allows the project to recognize some architectures
> > as "not supported" and don't be obligated to release a GLSA for that
> > specific architecture when an issue arises.
>
>
> I personally don't agree with part of this section; security is
> relative, and if it is stated to not be supported there are no security
> assumptions. If anything the removal of these arches as security
> supported demonstrates an active decisions not to support them, and
> signals to users of these arches that they can't depend on security
> information from Gentoo. Stable generally means a stable tree of
> dependencies, without security assumptions, if this is e.g used in a
> closed lab that likely doesn't impact much.
>
> So comments welcome
>

Really this seems to be the primary problem with the status quo. Users tend
to select a keyword (typically arch, ~arch, or ** for a given architecture
keyword.) The security team already publishes a list of arch keywords that
received security support. So in theory, curious users can of course, go
read the list and see if their keyword is there.

The problem of course is that the keywords have names. We might map
["arch", "~arch", "**"][0] to "stable", "testing", and "unknown state" and
the issue is that when users hear terms like "the stable arm tree" there is
an implicit "stable X tree is security supported." This is of course not
true, and the security team already publishes a list of arches that receive
security support at their project page.

If we compare again to Debian (begin the hate!) they work in a similar way
to this proposal. In order to offer a stable package repository, you must
be security supported. This means that ports with less staffing don't have
a stable repository, they only have -unstable or -testing. However, Debian
employs significant automation to gate packages and only has to support
binary packages their repository, not compilation. I wouldn't necessarily
encourage adopting their model. One thing I enjoy is that Debian has a
clear FAQ outlining how to get security support (It says run debian stable,
in case you are curious) and so one benefit is that it becomes obvious that
e.g. you cannot run a 'secure' sparc port, because there is no sparc stable
tree on offer from Debian.

We might emulate this by, for example, Implementing GLEP 72, shipping the
data in the tree, and then offering some kind of new match in make.conf.
For example we might say: "SECURITY_SUPPORT=stable" and ARCH="arm". Portage
would then look up "arm" in arch.desc, see that there are no "stable" "arm"
states available in the GLEP 72 compatible arches.desc and the fail to do
anything.

[0] I'm ignoring package.mask here, mostly because I debate its relevance
to this conversation. I suspect most users understand that "things in pmask
are not production ready" and thus its clearer to users that installing
pmask'd packages brings added risk (security or otherwise.)


> >
> >
> > Specification =============
> >
> > The Security Project's purpose is to ensure users in the stable
> > category of Gentoo are provided with applications that to the best of
> > the knowledge of the Gentoo Developers are free of vulnerabilities.
> > In order to achieve this purpose, the Security Project require
> > certain abilities and responsibilities as outlined in this GLEP in
> > order to ensure the best interests of all users.
> >
> > Security Project Lead
>
> Since the security project is moving into tree wide territory here, the
> following used to contain a section similar to GLEP 48 on council
> approval of leads, but that was removed in a later revision, so we
> welcome comments on the topic. Comments welcome.
>
> > ---------------------
> >
> > * The Security Project is required to have at least one Security
> > Project Lead. * The Security Project Lead is chosen at least yearly
> > by private or public election among the members of the Security
> > Project. * The Security Project Lead's term expires one year after
> > the voting is concluded. If the time expires the current Project Lead
> > retains the position until the security team can have another
> > election. In the case of Lead's definitive absence, the Security
> > Project must start the election process in a timely manner. * The
> > Security Project Lead can choose one member as a Deputy in case of
> > only one Lead. The Deputy has all of its powers directly delegated
> > from the Security Project Lead and thus the Deputy's actions and
> > decisions should be considered equal to those of the Security Project
> > Lead. * The Deputy is directly responsible to the Security Project
> > Lead and its actions reflects upon the Security Project Lead.
> >
> > Joining the Project -------------------
>
>
> For some reason, the following section on removal from the project
> received significant interest and as such became quite specific.
>

I wish I had a better idea for how to run projects in Gentoo, but I suspect
the lack of resources to develop sane leaders ends up leading to such
sections :/


>
> > Removal from Project --------------------
> No futher immediate comments, please see initial email
>

> EOF
>
>
You attached some RST, so I'm just going to do what you did and paste a
bunch in :)

Gentoo Linux supports several architectures and as such, it is vital
to ensure that each one of them is secure, especially those being used
by end-users. Because of that, the Security Team needs to be able to
remove an architecture from the "stable" category if all of the following
criteria are met:

* The architecture stabilization team is not capable to stabilize
  packages in a timely manner.
* The stabilization of packages takes longer than usual because of
  a specific architecture.
* The Security Team has informed the architecture team that they are
  downgrading the level of security of the "stable" version of  Gentoo.
* The Security Team has confirmed the lack of improvement after sending
  the information to the respective architecture team.
* The Security Team has requested the removal of the architecture to
  the Council and presented a report which explains why the named
  architecture needs to be removed from the "stable" version of Gentoo.


I'm eager to see a lot more tooling here about the state of architectures
and stability. Everyone loves reporting, right?

So for example Per Arch:

   - Number of Outstanding security bumps / stabilization(s).
   - Number of Late security bumps / stabilization(s). # A measure of, each
   GLSA that was 'late' because of this arch.

These two metrics seem to conform to the key items in 'why Security team
might downgrade an arch' and I'd love to see them on qa-reports.gentoo.org
in a public fashion. I really think it sets a nice narrative for Security
team (who should have lots of clear objective data to back up their
decisions) and also empower arch teams to manage these key cross-team
deliverables themselves.

-A

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

[-- Attachment #2: Type: text/html, Size: 11041 bytes --]