[llvm-dev] [RFC] LLVM Security Group and Process

[James Y Knight via llvm-dev]

On Tue, Nov 19, 2019 at 10:46 AM JF Bastien <jfbastien at apple.com> wrote:

> And I do agree that if someone were to come in and put in the significant
> amounts of work to make LLVM directly usable in security-sensitive places,
> then we could support that. But none of that should have anything to do
> with the security group or its membership. All of that work and discussion,
> and the decision to support it in the end, should be done as a project-wide
> discussion and decision, just like anything else that's worked on.
>
>
> Here’s where we disagree: how to get from nothing being security to the
> right things being security.
>
> I want to put that power in the hands of the security group, because
> they’d be the ones with experience handling security issues, defining
> security boundaries, fixing issues in those boundaries, etc. I’m worried
> that the community as a whole would legislate things as needing to be
> secure, without anyone in the security group able or willing to make it so.
> That’s an undesirable outcome because it sets them up for failure.
>
> Of course neither of us is saying that the community should dictate to the
> security group, nor that the security group should dictate to the
> community. It should be a discussion. I agree with you that, in that
> transition period from no security to right security there might be cases
> where the security group disappoints the community, behind temporarily
> closed doors. There might be mistakes, an issue which should have been
> treated as security related won’t be. I would rather trust the security
> group, expect that it’ll do outreach when it feels unqualified to handle an
> issue, and fix any mistakes it makes if it happens. Doing so is better than
> where we are today.
>

My worry is actually the inverse -- that there may be a tendency to treat
more issues as "security" than should be. When some bug is reported via the
security process, I suspect there will be a default-presumption towards
using the security process to resolve it, with all the downsides that go
along with that.

What I want is for it to be clear that certain kinds of issues are
currently explicitly out-of-scope. E.g. crashes/code-execution/etc
resulting from parsing or compiling untrusted C source-code with Clang, or
parsing/compiling untrusted bitcode with LLVM, or linking untrusted files
with LLD. These sorts of things should not, currently, be treated with a
"security" mindset. They're *bugs*, which should be fixed, but if
something's security depends on llvm being able to securely process
untrusted inputs, sorry, that's not reasonable. (And yes, that's maybe sad,
but is the reality right now). Until someone is willing to put in the
significant effort to make those processes generally secure for use on
untrusted inputs, handling individual bug-reports of this kind via a
special process is not going to realistically improve security.

Furthermore, if people disagree with the above paragraph, I'd like that
discussion to be had in the open ahead of time, rather than in private
after the first time such an issue is reported via a defined security
process.

It feels like you want the security team to be two different things:
1. A way to privately report security issues to LLVM, and a group of people
to privately work on fixing such issues, for a coordinated release.
2. A group of people working generally on defining or improving security
properties of LLVM.

I don't think these two need or should be linked, though some of the same
people might be involved in both.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191125/2f6ecb65/attachment.html>