[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210917161848.GB9168@openwall.com>
Date: Fri, 17 Sep 2021 18:18:48 +0200
From: Solar Designer <solar@...nwall.com>
To: Oleksandr Tymoshenko <ovt@...gle.com>
Cc: oss-security@...ts.openwall.com, Kees Cook <keescook@...omium.org>
Subject: Re: Containers-optimized OS (COS) membership in the linux-distros list
Hello Oleksandr,
You posted this from @google.com, which probably means many subscribers
didn't receive the message because of that domain's strict DMARC policy.
So I fully quote your message below for others to possibly comment.
BTW, you will similarly need to be posting from another domain (e.g.,
gmail.com) to the linux-distros list.
Overall, your proposal looks reasonable to me at first glance.
Please also propose which specific contributing-back task(s) your team
would like to help with.
Thanks,
Alexander
On Thu, Sep 16, 2021 at 11:12:21PM -0700, Oleksandr Tymoshenko wrote:
> Hello,
>
>
> I???d like to propose Container-Optimized OS (COS) for membership in
> linux-distros. Text below addresses items listed in the ???Membership
> criteria??? section of
> https://oss-security.openwall.org/wiki/mailing-lists/distros
>
>
> > 1. Be an actively maintained Unix-like operating system distro with
> > substantial use of Open Source components
>
>
> Container-Optimized OS (COS) s a Chromium OS based
> server operating system. Google distributes COS as a pre-built cloud image,
> but also provides sources for users to customize and build their own
> specialized versions of the OS.
>
>
> URL: https://cloud.google.com/container-optimized-os
>
>
> Source code: https://cos.googlesource.com
> Build instructions:
> https://cloud.google.com/container-optimized-os/docs/how-to/building-from-open-source
>
>
> COS has a 6-month major release cadence and 3 LTS branches with their own
> 3-month refresh cadence. Critical security vulnerabilities addressed in
> patch releases, independently from the release/refresh cycle.
>
>
> Release notes: https://cloud.google.com/container-optimized-os/docs/release-notes
>
>
> > 2. Have a user base not limited to your own organization
>
>
> COS is available directly to external customers as a base VM image for the
> Google Compute Engine and indirectly as a base OS for managed services such
> as Google Kubernetes Engine (GKE), CloudSQL, Google Cloud Filestore.
> Overall usage of COS adds up to millions of cloud instances.
>
>
> > 3. Have a publicly verifiable track record, dating back at least 1 year and
> > continuing to present day, of fixing security issues (including some that
> > had been handled on (linux-)distros, meaning that membership would have
> > been relevant to you) and releasing the fixes within 10 days (and
> > preferably much less than that) of the issues being made public (if it
> > takes you ages to fix an issue, your users wouldn't substantially benefit
> > from the additional time, often around 7 days and sometimes up to 14 days,
> > that list membership could give you)
>
>
> Some of the examples of COS reacting quickly (less than 7 days) to CVEs
> with high impact:
>
>
> CVE-2021-33909(Sequoia):
> https://cloud.google.com/container-optimized-os/docs/release-notes/m85#cos-85-13310-1308-6
>
>
> CVE-2020-14308, CVE-2020-14311, CVE-2020-15705 (GRUB2):
> https://cloud.google.com/container-optimized-os/docs/release-notes/m81#cos-81-12871-1185-0
>
>
> CVE-2020-14386:
> https://cloud.google.com/container-optimized-os/docs/release-notes/m81#cos-81-12871-1196-0
>
>
> Having access to embargoed CVEs would have helped us to plan and prepare
> for patch releases in a more proactive way.
>
>
> > 4. Not be (only) downstream or a rebuild of another distro (or else we need
> > convincing additional justification of how the list membership would enable
> > you to release fixes sooner, presumably not relying on the upstream distro
> > having released their fixes first?)
>
>
> Although COS is derived from Chromium OS we switched to maintaining our own
> kernel package that tracks more recent versions of the Linux kernel. We
> make an effort to keep it as close to the upstream kernel as possible. We
> also track releases of other open-source packages relevant for our use
> cases independently from Chromium OS or Gentoo.
>
>
> > 5. Be a participant and preferably an active contributor in relevant public
> > communities (most notably, if you're not watching for issues being made
> > public on oss-security, which are a superset of those that had been handled
> > on (linux-)distros, then there's no valid reason for you to be on
> > (linux-)distros)
>
>
> We are actively monitoring multiple sources of information about
> vulnerabilities but haven???t contributed much directly because we didn't
> have anything to add to discussions. We contributed to OSTIF Linux Kernel
> Vuln Reporting/Remediation Practices review, and also monitor the
> oss-security indirectly via ChromeOS.
>
>
>
>
> > 6. Accept the list policy:
> > http://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-members
>
>
> Please consider this note as acceptance of the list policy.
>
>
> > 7. Be able and willing to contribute back, preferably in specific ways
> > announced in advance (so that you're responsible for a specific area and so
> > that we know what to expect from which member), and demonstrate actual
> > contributions once you've been a member for a while:
> > http://oss-security.openwall.org/wiki/mailing-lists/distros#contributing-back
>
>
> Our team can perform administrative tasks that benefit the wider community
> and also can draw upon Google???s internal kernel expertise if required (on
> the need-to-know basis, maintaining confidentiality).
>
>
> > 8. Be able and willing to handle PGP-encrypted e-mail
>
>
> We???ll provide relevant GPG keys separately if our membership is accepted.
>
>
> > 9. Have someone already on the private list, or at least someone else who
> > has been active on oss-security for years but is not affiliated with your
> > distro nor your organization, vouch for at least one of the people
> > requesting membership on behalf of your distro (then that one vouched-for
> > person will be able to vouch for others on your team, in case you'd like
> > multiple people subscribed)
>
>
> Kees Cook (Cc-ed) can vouch for the proposed candidates.
>
>
> Thank you
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
