llvm dev - Oct 2020 - LLVM security group round table - minutes

Thank you to everyone who contributed to the LLVM security group round table!

Please find the minutes and a few identified actions below.

Thanks,

Kristof

—

When: Thu. Oct 8, 2020 11:35 AM - 12:10 PM
Where: https://whova.com/portal/webapp/llvm_202010/Agenda/1274493
Intro:
Let's discuss the current status and next steps for the LLVM security group,
which has recently been formed. See http://llvm.org/docs/Security.html. There
are quite a few “FUTURE” markers in that document that need to be defined, so we
could talk about how to get those defined. But other topics related to the
security group are also in-scope for this round table.
Minutes:

  *
An issue was reported in the wild (stack clash protector related). Serge (the
author) implemented a fix after the issue was published publicly. Should that
issue have been discussed privately in the security group?
     *
Once an issue is publicly visible, it typically is worse to try and keep it
private - but it always needs judgement (e.g. years-old bugs that are ignored
and later discovered to have a security impact should be considered as “not
publicly disclosed yet”).
  *
How do (or should) we actually report a security issue?
     *
github tooling might work. But the tooling is not there yet it seems (Matthew’s
experience). E.g. The Chromium bug tracker has more of the needed features.
     *
Matt proposes straightforward email (results in low barrier to entry). Is
unlikely to break. With reasonable operational security?
     *
The board was not interested in being involved in running the security group.
The security group should be competent in managing the security infrastructure
needs it has.
     *
in Rust community: uses email, a shared GPG key for reporting. For the llvm
group (which changes more often), this may be harder. Sometimes reports are
encrypted, sometimes not.
        *
Experience with github issues: access control is tricky (e.g. admins are always
in the thread); As soon as the issue is made public, the issue is locked - not
possible to continue having private comments. For mail servers, the Rust mail
infrastructure is used.
     *
Matt: Google groups exist and would trust that.
        *
Administrators need a Google account, others don’t. Would this be too much of a
barrier for the LLVM security group?
     *
Matt: on demanding GPG: actual level of security increase is minimal and it adds
barriers.

Just email is probably better; or a https web form (running on
llvm.org<http://llvm.org>)

  *
Needs to be discussed further by the llvm security group to progress this (let’s
leave some time for other topics too in this round table).
  *
We should also reach out to github, reporting shortcomings found by github
security tooling. Google is already reaching out.

  *
What is in scope; what is in scope for a security issue? Should we provide some
guidance?
     *
Right now it's wide open. That is currently on purpose, because the security
surface will presumably evolve over time. E.g. what level of security
maintenance the LLVM community wants to invest for specific things may evolve
over time.
     *
As an example, on the Rust project: there are no guidelines. The security group
triages issues that are reported and encourages to report all issues that could
be assumed to be a security issue.
     *
Guidelines we should post for self-triaging: we can post a list of items of
things that we don’t consider a security issue (an example could be a bug that
causes clang to crash?). So try to define what is not a security issue, don’t
try to define what is definitely a security issue? Then we can have a discussion
on what would be needed for specific things to be considered a security
component.
     *
Example of exclusion: arbitrary attacker-controlled IR not supported?
     *
This discussion (what is and is not considered a security issue) should be
discussed publicly and refined over time.
        *
But also a remark that full reasoning on a public mailing list discussing the
boundaries of what is considered security sensitive is not ideal - best to make
it possible to have some of that discussion in a smaller group (the discussion
itself may be sensitive).
  *
We could improve the process by testing the process with a “fake” security
issue, e.g. one of the security group members reporting a fake security issue
and going through the process as if it was a real one to pipe clean the process.
  *
Do we need some form of rotation to ensure a level of SLO? It needs to be
obvious who will take action? Who will be the champion?
     *
Either we need a rotation; or we need to remove commitments (e.g. time scales on
which actions will be taking).
     *
Champion here is the person responsible for chasing up progress, not necessarily
making progress themselves.
     *
No precedence for this kind of SLA/SLO in the LLVM community.
     *
e.g. in Rust, expect 24h/48h to get a response. If you don’t get a response,
there are guidelines on how to escalate in other ways.
     *
Pietro is going to propose an update to the security process similar to this.
(see https://reviews.llvm.org/D89068)
  *
Kristof to send an email to the security group with this report.
  *
We need to be able to have a regular kind of sync-up.
  *
Quickly being able to do a video call to discuss incoming security issues seems
useful.

Identified actions:

  *
Define how to report security issues (includes setting up a communication
channel for the security group). Matthew Riley already started taking the lead
on this.
  *
Define SLO and escalation path for first reaction on a security report. Pietro
Albini already taking action, see https://reviews.llvm.org/D89068.
  *
Kristof to share this report of the round table more widely.
  *
Someone to set up a regular kind of sync-up to continue making progress (Kristof
willing to organize this).
  *
The security group should be able to have a way to quickly organize a call
between themselves when needed (Kristof willing to look into what the options
are for this).

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201013/490a23ba/attachment-0001.html>