Security Policy
===============

To report a vulnerability see "Reporting a Vulnerability" below.


Security Incident Policy
========================

Security bug reports are treated with special attention and are handled
differently from normal bugs. In particular, security sensitive bugs are not
handled in public but in private. Information about the bug and access to it
is restricted to people in the security group, the individual engineers that
work on fixing it, and any other person who needs to be involved for organisational
reasons. The process is handled by the security team, which decides on the people
involved in order to fix the issue. It is also guaranteed that the person reporting
the issue has visibility into the process of fixing it. Any security issue gets
prioritized according to its security rating. The issue is opened up to the public
in coordination with the release schedule and the reporter.


Disclosure Policy
=================

Everyone involved in the handling of a security issue - including the reporter -
is required to adhere to the following policy. Any information related to
a security issue must be treated as confidential and only shared with trusted
partners if necessary, for example to coordinate a release or manage exposure
of clients to the issue. No information must be disclosed to the public before
the embargo ends. The embargo time is agreed upon by all involved parties. It
should be as short as possible without putting any users at risk.


Supported Versions
==================

Only the most recent version of the GRUB is supported.


Reporting a Vulnerability
=========================

The security report should be encrypted with the PGP keys and sent to ALL email
addresses listed below. Every vulnerability report will be assessed within
72 hours of receiving it. If the outcome of the assessment is that the report
describes a security issue, the report will be transferred into an issue on the
internal vulnerability project for further processing. The reporter is updated
on each step of the process.

While there's currently no bug bounty program we appreciate every report.

* Contact: Marta Lewandowska <mlewando@redhat.com>
* PGP Key Fingerprint: 5B21 5739 7348 6620 C0FF  7073 DDF0 92F7 4C8F 619B

* Contact: Leonardo Sandoval Gonzalez <lsandova@redhat.com>
* PGP Key Fingerprint: DFB6 2CC1 A987 E6C7 6EBF  8143 916E C070 8CDF DDFD

* Contact: Alex Burmashev <alexander.burmashev@oracle.com>
* PGP Key Fingerprint: 50A4 EC06 EF7E B84D 67E0  3BB6 2AE2 C87E 28EF 2E6E

* Contact: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
* PGP Key Fingerprint: E53D 497F 3FA4 2AD8 C9B4  D1E8 35A9 3B74 E82E 4209

Reporting AI-assisted Vulnerabilities
=====================================

If the vulnerability was found using AI assistance the reporter needs to
disclose that within the report, also needs to mention which AI was used
during the processes.

The report should take into account the security boundaries associated with
GRUB and the security measures (such as Secure Boot) GRUB is designed to provide.
To be considered a vulnerability the issue should be reachable by some realistic
attack path (some source of untrusted data that GRUB is intended / should mitigate)
and have the potential to affect the integrity or confidentiality  or in some rare
cases availability of GRUB or its downstream software to be executed.

Additionally, when basing the report in ASAN or fuzzing outputs, the reporter should
try at most to justify why the issue poses a boundary of trust break or how the detected
bug can be leveraged to match the criterias written bellow.

This will help save triage time and will provide a more solid resonability
in triggering a possible time expensive cross-industry vulnerability
disclosure coordination and remediation process.

Types of bugs or threat models that are not a CVE worthy initially
==================================================================

Some kinds of attack vectors or threat models, although valid, exceeds
the GRUB's responsability to defend against; or given how GRUB works are not
appliable for CVEs as it's on other user-space related software. The list
bellow are not set in stone and if the reporter provides a reasonable
justification can be turned into security vulnerabilities:

1) Evil maid like attacks:

Attacks that involves physical access to the device such as ones that
	- Requires hard drives to be changed or added to the targeted machine;
	- Requires the attacker to change the firmware settings

Won't have CVEs issued against since an attacker with such access may cause
more damage in a more simple way than trying to leverage any weaknesses in GRUB

2) Heap Out-of-bound reads and writes smaller than the system address width:

Unless proven it can leak sensitive data or can be used to bypass Secure Boot
features, such category of bugs will be handled as hardenings. The same applies
for ASAN reports without proper justification on how the flaw can be leveraged
to cross any trust boundary imposed by Secure Boot or lockdown mechanisms.

3) Weaknesses that the most likely outcome is lead GRUB to crash/hang only:

Although it may represent an availability impact, such issues can be handled as
any other standard bug. Some exception may be made by issues that can be triggered
remotely without the need to have user interaction to connect to a malicious remote
party.

While on this realm, issue that requires high privileges to cause availability
disruptions will also be handled as standard bugs instead as any user with
privileges enough to change Firmware settings, configuration files or perform
key management in the target will likely have privileges to cause the same amount
of damage without requiring more complex exploit.

4) Attacks that requires a valid signed crafted binary

If the binary has a valid signature it was reviewed by the signer party and is
trusted by default, the same is valid if the attacker may need to enroll the hash
via MOK.

If the attack, for some reason, requires the binary signature to be exchanged by
other valid signature when being read by grub the same approach will be used.

5) Flaws in features or functions intended to be enabled on development only:

Possible security issues on functions that are not intended to be used in production
environments won't be elegible for a CVE ID. That includes GDB and test scripts for
example.

6) Issues specific to architectures or targets intended for development only:

Similar to the previous topic, reports for architectures or build targets that
are mainly intended for development use only won't be handled as security issues.

7) Issues in cryptographic modules marked as cryptographically broken in the GRUB manual

8) Issues in features or functions marked as deprecated or disable by the lockdown mode:

Features that are marked as deprecated won't have CVE assigned as they are no longer maintained.
The same is true for features that are disabled by lockdown mode, unless proven it can be leveraged
to bypass Secure Boot protections.
