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

[Alec Warner <antarus@gentoo.org>]

[-- 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 --]