[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACGj0Cg_OgsYUAw8R6cbHr+ihPjfrKUJw0RjVewzuWYVi8tXpg@mail.gmail.com>
Date: Thu, 16 Sep 2021 23:12:21 -0700
From: Oleksandr Tymoshenko <ovt@...gle.com>
To: oss-security@...ts.openwall.com
Cc: Kees Cook <keescook@...omium.org>
Subject: Containers-optimized OS (COS) membership in the linux-distros list
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.
