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

[Dimitry Andric via llvm-dev]

On 15 Nov 2019, at 19:58, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> The Apple LLVM team would like to propose that a new a security process and an associated private LLVM Security Group be created under the umbrella of the LLVM project.
> 
> A draft proposal for how we could organize such a group and what its process could be is available on Phabricator <https://reviews.llvm.org/D70326>. The proposal starts with a list of goals for the process and Security Group, repeated here:
> 
> The LLVM Security Group has the following goals:
> Allow LLVM contributors and security researchers to disclose security-related issues affecting the LLVM project to members of the LLVM community.
> Organize fixes, code reviews, and release management for said issues.
> Allow distributors time to investigate and deploy fixes before wide dissemination of vulnerabilities or mitigation shortcomings.
> Ensure timely notification and release to vendors who package and distribute LLVM-based toolchains and projects.
> Ensure timely notification to users of LLVM-based toolchains whose compiled code is security-sensitive, through the CVE process <https://cve.mitre.org/>.
> 
> We’re looking for answers to the following questions:
> On this list: Should we create a security group and process?
Yes, I think that is a good idea.

> On this list: Do you agree with the goals listed in the proposal?
Yes, but I hope we can clarify what "time to investigate" and "timely notification" means, in more precise terms.

> On this list: at a high-level, what do you think should be done differently, and what do you think is exactly right in the draft proposal?
With regards to the embargo time limits, I think that 90 days is a rather long minimum time.  Remember that major LLVM release cycles are just ~180 days!  Then again, I realize that some downstream organizations have very elaborate release cycle procedures.  I just wish they were shorter for critical security issues.

I also think that fourteen weeks from a commit landing to making the issue public is not really doable.  Are we really going to commit something with a message "what this commit does is a secret, see you in 14 weeks" ?  And then expect nobody to just look at what the changes entail, and derive the actual issue from that?  It seems unrealistic, to say the least.

> On the Phabricator code review: going into specific details, what do you think should be done differently, and what do you think is exactly right in the draft proposal?
I'll post the above on the review

> On this list: to help understand where you’re coming from with your feedback, it would be helpful to state how you personally approach this issue:
> Are you an LLVM contributor (individual or representing a company)?
I am both an individual contributor to LLVM, and a member of the FreeBSD community, where I am mostly responsible for maintaining the LLVM fork (well, just plain LLVM with a few hacks and additional patches) in the FreeBSD source tree.

> Are you involved with security aspects of LLVM (if so, which)?
Not especially, though I have been involved with diagnosing quite a number of LLVM crash bugs, of which at least some could possibly be abused in security contexts.  That said, I have not been actively searching for any security holes.

> Do you maintain significant downstream LLVM changes?
No, we try to keep the differences between stock LLVM components and the FreeBSD versions as small as possible.  We do, however apply a few minor customizations, and quite a number of post-release patches.  Most of these are to fix issues with compiling the rather large FreeBSD ports collection (roughly 33,000 of them), for a number of different architectures.

> Do you package and deploy LLVM for others to use (if so, to how many people)?
Yes, we build LLVM components such as clang, compiler-rt, libc++, lld, lldb and a number of llvm tools as part of the FreeBSD base system.  These are shipped as releases in binary and source code form.  Regular snapshots (roughly every week) are also made available.

FreeBSD is used by quite a number of people and organizations, but since the project does not actively track its users, I don't know any hard (or even semi-soft :) numbers.  There are also a number of projects downstream from FreeBSD, such as FreeNAS and TrueOS.

> Is your LLVM distribution based on the open-source releases?
Yes, and almost all the patches we apply are from the regular LLVM trunk or master.

> How often do you usually deploy LLVM?
Normally we update to each new major and minor release as they appear, and we are also involved in the testing process before those releases.  Since not every bug that affects FreeBSD can get fixed, we also regularly apply fixes post LLVM releases.

> How fast can you deploy an update?
If any issue affects a released version of FreeBSD, it will be handled by the FreeBSD Security Team.  They will investigate the severity of the issue and the impact, verify if the fix(es) apply and have the promised mitigating effect, and obviously determine if there are no negative side effects.  Then they will build new binary bits that go out via the binary update system we use, a.k.a freebsd-update.  Building the bits can be done in a few days, but the investigation is harder to pin down time-wise.

> Does your LLVM distribution handle untrusted inputs, and what kind?
The toolchain parts, e.g. clang, lld and lldb, can obviously be used for arbitrary source code, but will seldom be useful for e.g. privilege escalations.  Other parts, such as compiler-rt and libc++, are installed as system wide dynamic libraries.  Vulnerabilities in these could affect any application on the system which links to them.

> What’s the threat model for your LLVM distribution?
As described in the previous item, specifically the compiler-rt and libc++ libraries can be dependencies of many applications, some of which will be part of the system, and also be security sensitive.  (For example, FreeBSD's device daemon devd <https://www.freebsd.org/cgi/man.cgi?query=devd> is written in C++, and linked to libc++.)

> 
> Other open-source projects have security-related groups and processes. They structure their group very differently from one another. This proposal borrows from some of these projects’ processes. A few examples:
> https://webkit.org/security-policy/ <https://webkit.org/security-policy/>
> https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md <https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md>
> https://wiki.mozilla.org/Security <https://wiki.mozilla.org/Security>
> https://www.openbsd.org/security.html <https://www.openbsd.org/security.html>
> https://security-team.debian.org/security_tracker.html <https://security-team.debian.org/security_tracker.html>
> https://www.python.org/news/security/ <https://www.python.org/news/security/>When providing feedback, it would be great to hear if you’ve dealt with these or other projects’ processes, what works well, and what can be done better.

I haven't interacted with any of the above security groups.  But I have interacted with the FreeBSD Security Team, which has a page here <https://www.freebsd.org/security/>. Their process is fairly straightforward, and most of it is handled via email and a private Bugzilla instance.

-Dimitry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191205/f609fb2b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191205/f609fb2b/attachment.sig>