llvm/docs/Security.rst

   1 ===================
   2 LLVM Security Group
   3 ===================
   4
   5 The LLVM Security Group has the following goals:
   6
   7 1. Allow LLVM contributors and security researchers to disclose security-related issues affecting the LLVM project to members of the LLVM community.
   8 2. Organize fixes, code reviews, and release management for said issues.
   9 3. Allow distributors time to investigate and deploy fixes before wide dissemination of vulnerabilities or mitigation shortcomings.
  10 4. Ensure timely notification and release to vendors who package and distribute LLVM-based toolchains and projects.
  11 5. Ensure timely notification to users of LLVM-based toolchains whose compiled code is security-sensitive, through the `CVE process`_.
  12 6. Strive to improve security over time, for example by adding additional testing, fuzzing, and hardening after fixing issues.
  13
  14 *Note*: these goals ensure timely action, provide disclosure timing when issues are reported, and respect vendors' / packagers' / users' constraints.
  15
  16 The LLVM Security Group is private. It is composed of trusted LLVM contributors. Its discussions remain within the Security Group (plus issue reporter and key experts) while an issue is being investigated. After an issue becomes public, the entirety of the group’s discussions pertaining to that issue also become public.
  17
  18 .. _report-security-issue:
  19
  20 How to report a security issue?
  21 ===============================
  22
  23 To report a security issue in the LLVM Project, please `open a new issue`_ in the LLVM project page, on the chromium issue tracker.  Be sure to use the "Security bug report" template.
  24
  25 We aim to acknowledge your report within two business days since you first reach out. If you do not receive any response by then, you can escalate by posting on the `Discourse forums`_ asking to get in touch with someone from the LLVM Security Group. **The escalation mailing list is public**: avoid discussing or mentioning the specific issue when posting on it.
  26
  27
  28 Group Composition
  29 =================
  30
  31 Security Group Members
  32 ----------------------
  33
  34 The members of the group represent a wide cross-section of the community, and
  35 meet the criteria for inclusion below. The list is in the format
  36 `* ${full_name} (${affiliation}) [${github_username}]`. If a github
  37 username for an individual isn't available, the brackets will be empty.
  38
  39 * Ahmed Bougacha (Apple) [@ahmedbougacha]
  40 * Andy Kaylor (Intel) [@andykaylor]
  41 * Artur Pilipenko (Azul Systems Inc) []
  42 * Boovaragavan Dasarathan (Nvidia) [@mrragava]
  43 * Dimitry Andric (individual; FreeBSD) [@DimitryAndric]
  44 * Ed Maste (individual; FreeBSD) [@emaste]
  45 * George Burgess IV (Google) [@gburgessiv]
  46 * Josh Stone (Red Hat; Rust) [@cuviper]
  47 * Kate McInnes (Apple) []
  48 * Kristof Beyls (ARM) [@kbeyls]
  49 * Matthew Riley (Google) [@mmdriley]
  50 * Nikhil Gupta (Nvidia) []
  51 * Oliver Hunt (Apple) [@ojhunt]
  52 * Paul Robinson (Sony) [@pogo59]
  53 * Peter Smith (ARM) [@smithp35]
  54 * Pietro Albini (Ferrous Systems; Rust) [@pietroalbini]
  55 * Serge Guelton (Mozilla) [@serge-sans-paille]
  56 * Sergey Maslov (Intel) [@smaslov-intel]
  57 * Shayne Hiet-Block (Microsoft) [@GreatKeeper]
  58 * Tim Penge (Sony) []
  59
  60 Criteria
  61 --------
  62
  63 * Nominees for LLVM Security Group membership should fall in one of these groups:
  64
  65   - Individual contributors:
  66
  67     + Specializes in fixing compiler-based security related issues or often participates in their exploration and resolution.
  68     + Has a track record of finding security vulnerabilities and responsible disclosure of those vulnerabilities.
  69     + Is a compiler expert who has specific interests in knowing about, resolving, and preventing future security vulnerabilities.
  70     + Has actively contributed non-trivial code to the LLVM project in the last year.
  71
  72   - Researchers:
  73
  74     + Has a track record of finding security vulnerabilities and responsible disclosure of those vulnerabilities.
  75     + Is a compiler expert who has specific interests in knowing about, resolving, and preventing future security vulnerabilities.
  76
  77   - Vendor contacts:
  78
  79     + Represents an organization or company which ships products that include their own copy of LLVM. Due to their position in the organization, the nominee has a reasonable need to know about security issues and disclosure embargoes.
  80
  81 * Additionally, the following are necessary but not sufficient criteria for membership in the LLVM Security Group:
  82
  83   - If already in the LLVM Security Group, has actively participated in one (if any) security issue in the last year.
  84   - If already in the LLVM Security Group, has actively participated in most membership discussions in the last year.
  85   - If already in the LLVM Security Group, has actively participated in writing or reviewing a transparency report in the last year.
  86   - When employed by a company or other entity, the parent entity has no more than three members already in the LLVM Security Group.
  87   - When nominated as a vendor contact, their position with that vendor remains the same as when originally nominated.
  88   - Nominees are trusted by existing Security Group members to keep communications embargoed while still active.
  89
  90 Nomination process
  91 ------------------
  92
  93 Anyone who feels they meet these criteria can nominate themselves, or may be nominated by a third party such as an existing LLVM Security Group member. The nomination should state whether the nominee is nominated as an individual, researcher, or as a vendor contact. It should clearly describe the grounds for nomination.
  94
  95 For the moment, nominations are generally proposed, discussed, and voted on using Phabricator. An `example nomination is available here`_. The use of Phabricator helps keep membership discussions open, transparent, and easily accessible to LLVM developers in many ways. If, for any reason, a fully-world-readable nomination seems inappropriate, you may `open a new issue`_, and a discussion can be had about the best way to approach nomination, given the constraints that individuals are under.
  96
  97 Our recommended method of nomination may change as our `Discussion Medium`_ story evolves over time.
  98
  99 Choosing new members
 100 --------------------
 101
 102 If a nomination for LLVM Security Group membership is supported by a majority of existing LLVM Security Group members, then it carries within five business days unless an existing member of the Security Group objects. If an objection is raised, the LLVM Security Group members should discuss the matter and try to come to consensus; failing this, the nomination will succeed only by a two-thirds supermajority vote of the LLVM Security Group.
 103
 104 Accepting membership
 105 --------------------
 106
 107 Before new LLVM Security Group membership is finalized, the successful nominee should accept membership and agree to abide by this security policy, particularly `Privileges and Responsibilities of LLVM Security Group Members`_ below.
 108
 109 Keeping Membership Current
 110 --------------------------
 111
 112 * At least every six months, the LLVM Security Group applies the above criteria. The membership list is pruned accordingly.
 113 * Any Security Group member can ask that the criteria be applied within the next five business days.
 114 * If a member of the LLVM Security Group does not act in accordance with the letter and spirit of this policy, then their LLVM Security Group membership can be revoked by a majority vote of the members, not including the person under consideration for revocation. After a member calls for a revocation vote, voting will be open for five business days.
 115 * Emergency suspension: an LLVM Security Group member who blatantly disregards the LLVM Security Policy may have their membership temporarily suspended on the request of any two members. In such a case, the requesting members should notify the Security Group with a description of the offense. At this point, membership will be temporarily suspended for five business days, pending outcome of the vote for permanent revocation.
 116 * The LLVM Board may remove any member from the LLVM Security Group.
 117
 118 Transparency Report
 119 -------------------
 120
 121 Every year, the LLVM Security Group must publish a transparency report. The intent of this report is to keep the community informed by summarizing the disclosures that have been made public in the last year. It shall contain a list of all public disclosures, as well as statistics on time to fix issues, length of embargo periods, and so on.
 122
 123 The transparency reports are published at :doc:`SecurityTransparencyReports`.
 124
 125
 126 Privileges and Responsibilities of LLVM Security Group Members
 127 ==============================================================
 128
 129 Access
 130 ------
 131
 132 LLVM Security Group members will be subscribed to a private `Discussion Medium`_ (*FUTURE*: see section below). It will be used for technical discussions of security issues, as well as process discussions about matters such as disclosure timelines and group membership. Members have access to all security issues.
 133
 134 Confidentiality
 135 ---------------
 136
 137 Members of the LLVM Security Group will be expected to treat LLVM security issue information shared with the group as confidential until publicly disclosed:
 138
 139 * Members should not disclose security issue information to non-members unless both members are employed by the same vendor of a LLVM based product, in which case information can be shared within that organization on a need-to-know basis and handled as confidential information normally is within that organization.
 140 * If the LLVM Security Group agrees, designated members may share issues with vendors of non-LLVM based products if their product suffers from the same issue. The non-LLVM vendor should be asked to respect the issue’s embargo date, and to not share the information beyond the need-to-know people within their organization.
 141 * If the LLVM Security Group agrees, key experts can be brought in to help address particular issues. The key expert should be asked to respect the issue’s embargo date, and to not share the information.
 142
 143 Disclosure
 144 ----------
 145
 146 Following the process below, the LLVM Security Group decides on embargo date for public disclosure for each Security issue. An embargo may be lifted before the agreed-upon date if all vendors planning to ship a fix have already done so, and if the reporter does not object.
 147
 148 Collaboration
 149 -------------
 150
 151 Members of the LLVM Security Group are expected to:
 152
 153 * Promptly share any LLVM vulnerabilities they become aware of.
 154 * Volunteer to drive issues forward.
 155 * Help evaluate the severity of incoming issues.
 156 * Help write and review patches to address security issues.
 157 * Participate in the member nomination and removal processes.
 158
 159
 160 Discussion Medium
 161 =================
 162
 163 *FUTURE*: this section needs more work! Where discussions occur is influenced by other factors that are still open in this document. We can finalize it later.
 164 It seems like bugzilla and email don't meet security requirements.
 165
 166 The medium used to host LLVM Security Group discussions is security-sensitive. It should therefore run on infrastructure which can meet our security expectations.
 167
 168 We are currently using the `chromium issue tracker`_ (as the `llvm` project) to have security discussions:
 169
 170 * File security issues.
 171 * Discuss security improvements to LLVM.
 172
 173 When a new issue is filed, a template is provided to help issue reporters provide all relevant information.
 174
 175 *FUTURE*: The `Github security`_ workflow allows publicly disclosing resolved security issues on the github project page, and we would be interested in adopting it for that purpose.  However, it does not easily allow confidential reporting of security issues, as creating Github Security Advisories is currently restricted to Github project admins.  That is why we have started with the `chromium issue tracker`_ instead.
 176
 177
 178 We also occasionally need to discuss logistics of the LLVM Security Group itself:
 179
 180 * Nominate new members.
 181 * Propose member removal.
 182 * Suggest policy changes.
 183
 184 We often have these discussions publicly, in our :ref:`monthly public sync-up call <online-sync-ups>` and on the Discourse forums.  For internal or confidential discussions, we also use a private mailing list.
 185
 186 Process
 187 =======
 188
 189 The following process occurs on the discussion medium for each reported issue:
 190
 191 * A security issue reporter (not necessarily an LLVM contributor) reports an issue.
 192 * Within two business days, a member of the Security Group is put in charge of driving the issue to an acceptable resolution. This champion doesn’t need to be the same person for each issue. This person can self-nominate.
 193 * Members of the Security Group discuss in which circumstances (if any) an issue is relevant to security, and determine if it is a security issue.
 194 * Negotiate an embargo date for public disclosure, with a default minimum time limit of ninety days.
 195 * Security Group members can recommend that key experts be pulled in to specific issue discussions. The key expert can be pulled in unless there are objections from other Security Group members.
 196 * Patches are written and reviewed.
 197 * Backporting security patches from recent versions to old versions cannot always work. It is up to the Security Group to decide if such backporting should be done, and how far back.
 198 * The Security Group figures out how the LLVM project’s own releases, as well as individual vendors’ releases, can be timed to patch the issue simultaneously.
 199 * Embargo date can be delayed or pulled forward at the Security Group’s discretion.
 200 * The issue champion obtains a CVE entry from MITRE_.
 201 * Once the embargo expires, the patch is posted publicly according to LLVM’s usual code review process.
 202 * All security issues (as well as nomination / removal discussions) become public within approximately fourteen weeks of the fix landing in the LLVM repository. Precautions should be taken to avoid disclosing particularly sensitive data included in the report (e.g. username and password pairs).
 203
 204
 205 Changes to the Policy
 206 =====================
 207
 208 The LLVM Security Policy may be changed by majority vote of the LLVM Security Group. Such changes also need to be approved by the LLVM Board.
 209
 210
 211 What is considered a security issue?
 212 ====================================
 213
 214 The LLVM Project has a significant amount of code, and not all of it is
 215 considered security-sensitive. This is particularly true because LLVM is used in
 216 a wide variety of circumstances: there are different threat models, untrusted
 217 inputs differ, and the environment LLVM runs in is varied. Therefore, what the
 218 LLVM Project considers a security issue is what its members have signed up to
 219 maintain securely.
 220
 221 As this security process matures, members of the LLVM community can propose that
 222 a part of the codebase be designated as security-sensitive (or no longer
 223 security-sensitive). This requires a rationale, and buy-in from the LLVM
 224 community as for any RFC. In some cases, parts of the codebase could be handled
 225 as security-sensitive but need significant work to get to the stage where that's
 226 manageable. The LLVM community will need to decide whether it wants to invest in
 227 making these parts of the code securable, and maintain these security
 228 properties over time. In all cases the LLVM Security Group should be consulted,
 229 since they'll be responding to security issues filed against these parts of the
 230 codebase.
 231
 232 If you're not sure whether an issue is in-scope for this security process or
 233 not, err towards assuming that it is. The Security Group might agree or disagree
 234 and will explain its rationale in the report, as well as update this document
 235 through the above process.
 236
 237 The security-sensitive parts of the LLVM Project currently are the following.
 238 Note that this list can change over time.
 239
 240 * None are currently defined. Please don't let this stop you from reporting
 241   issues to the security group that you believe are security-sensitive.
 242
 243 The parts of the LLVM Project which are currently treated as non-security
 244 sensitive are the following. Note that this list can change over time.
 245
 246 * Language front-ends, such as clang, for which a malicious input file can cause
 247   undesirable behavior. For example, a maliciously crafted C or Rust source file
 248   can cause arbitrary code to execute in LLVM. These parts of LLVM haven't been
 249   hardened, and compiling untrusted code usually also includes running utilities
 250   such as `make` which can more readily perform malicious things.
 251
 252
 253 .. _CVE process: https://cve.mitre.org
 254 .. _open a new issue: https://bugs.chromium.org/p/llvm/issues/entry
 255 .. _chromium issue tracker: https://crbug.com
 256 .. _GitHub security: https://help.github.com/en/articles/about-maintainer-security-advisories
 257 .. _Discourse forums: https://discourse.llvm.org
 258 .. _MITRE: https://cve.mitre.org
 259 .. _example nomination is available here: https://reviews.llvm.org/D99232