[llvm-dev] LLVM security group round table - minutes

[Kristof Beyls via llvm-dev]

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>