[gentoo-dev-announce] [pre-glep] Security Project Structure

[gentoo-dev-announce] [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 --]