From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id E3874138334 for ; Thu, 6 Dec 2018 22:41:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4F4EBE09E4; Thu, 6 Dec 2018 22:41:18 +0000 (UTC) Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C826CE09E3 for ; Thu, 6 Dec 2018 22:41:17 +0000 (UTC) Received: by mail-ed1-f54.google.com with SMTP id d3so2146112edx.7 for ; Thu, 06 Dec 2018 14:41:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=UmlCvkbG2BOLje9IVKCVSloMihWZyPacLJnj1lNfKhg=; b=RpB8mUd64BWupYzg3ZGBdDvj8gLkj9b+nDMNNO4Lrkl6qTMpMr0QvD2ShIZRRRT6Cq UqU9JlhtxzGHq3a/Na4WPzzAVsfG9fM5Tle8h6QCOxWQw8NbpiO9TLBrWbgdthUPuu8r 7Q8hor9U+yLSlEJXC0nEs4O/2o6zAbUjxNkaelsF57EzyvQOOylUMpHeBMEg1KpbduqP tzVwM4gKpEWps3dJS/hPtsZiZ/KyKT+5kQRp8zO3/PwSPI08UBNkjHehbbAhxP3Bqa5E 9ichB/+2IDZsYqn9A2gNFLuPgAVTLpNf4bsW+UqA+URJ1zs9aaEA9ap5deawnDMi9tiM cQsg== X-Gm-Message-State: AA+aEWaamd9tcQM47jwcmLBbG8xTwIQ0xwbq3lMACcVL+aUiw8eQ2JTB JZTdBbuhZPy7sM+juXZDLMOgWO+cDPszsJPF7ZL+Ymv9L946/g== X-Google-Smtp-Source: AFSGD/V3KMQfSEsF3SakscBgomhpMOGrv347NnEdZ1ECHNLuFKbDAJYxkGDU31dV72lAAXnkAQ2Zf+Y8xKIZvTEGIz4= X-Received: by 2002:a50:94f4:: with SMTP id t49mr176581eda.24.1544136075827; Thu, 06 Dec 2018 14:41:15 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <6137e99b-2995-0569-9d3d-250924fdf116@gentoo.org> <1d3c9d30-5570-de92-3da9-75bd33c02075@gentoo.org> In-Reply-To: <1d3c9d30-5570-de92-3da9-75bd33c02075@gentoo.org> From: Alec Warner Date: Thu, 6 Dec 2018 17:41:04 -0500 Message-ID: Subject: Re: [gentoo-project] Re: [pre-glep] Security Project Structure To: gentoo-project Content-Type: multipart/alternative; boundary="00000000000048f802057c623221" X-Archives-Salt: 1d9240bc-487d-4b83-9535-7145ec6a6a2a X-Archives-Hash: 78d3a77e417dab545991f127a3c4f02c --00000000000048f802057c623221 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 4, 2018 at 4:05 PM Kristian Fiskerstrand 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 > > --00000000000048f802057c623221 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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 =3D=3D=3D=3D=3D=3D=3D=3D
>
> This GLEP outlines the abilities and purpose of the Gentoo Security > Project.
>
> Motivation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> 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 softw= are
> 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 obvi= ous that
> the current policy regarding "supported" and "not=C2=A0= 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<= br> > 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<= br> > participation.
>
> The current policy of having a "supported" list of architect= ures 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 G= LSA 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 t= o be the primary problem with the status quo. Users tend to select a keywor= d (typically arch, ~arch, or ** for a given architecture keyword.) The secu= rity 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 se= e if their keyword is there.

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

If we compare again to Debian (be= gin the hate!) they work in a similar way to this proposal. In order to off= er 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 sec= urity support (It says run debian stable, in case you are curious) and so o= ne benefit is that it becomes obvious that e.g. you cannot run a 'secur= e' sparc port, because there is no sparc stable tree on offer from Debi= an.

We might emulate this by, for example, Impleme= nting GLEP 72, shipping the data in the tree, and then offering some kind o= f new match in make.conf. For example we might say: "SECURITY_SUPPORT= =3Dstable" and ARCH=3D"arm". Portage would then look up &quo= t;arm" in arch.desc, see that there are no "stable" "ar= m" 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 suspec= t most users understand that "things in pmask are not production ready= " and thus its clearer to users that installing pmask'd packages b= rings added risk (security or otherwise.)


>
>
> Specification =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The Security Project's purpose is to ensure users in the stable > category of Gentoo are provided with applications that to the best of<= br> > 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<= br> > retains the position until the security team can have another
> election. In the case of Lead's definitive absence, the Security <= br> > 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<= br> > 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 project= s in Gentoo, but I suspect the lack of resources to develop sane leaders en= ds up leading to such sections :/
=C2=A0

> 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 severa=
l 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 f=
ollowing
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  G=
entoo.
* 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 G=
entoo.
=C2=A0
I'm eager to see a lot more too= ling here about the state of architectures and stability. Everyone loves re= porting, right?

So for example Per Arch:
  • Number of Outstanding security bumps / stabilization(s).
  • N= umber of Late security bumps / stabilization(s). # A measure of, each GLSA = that was 'late' because of this arch.
These two metri= cs seem to conform to the key items in 'why Security team might downgra= de 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 m= anage 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

--00000000000048f802057c623221--