Unikraft Security Policy

Unikraft is still in development phase; not all security features have been implemented. Nevertheless, the Unikraft project takes security seriously, and welcomes all security contributions.

Summary:

  1. Reporting Security Vulnerabilities
  2. The Unikraft Security Team
  3. What is Considered a Unikraft Security Vulnerability?
  4. Responsible Disclosure
  5. Security Q&A

1. Reporting Security Vulnerabilities

If you think you have found a security vulnerability in Unikraft, we invite you to report it privately to us through on our GitHub Security tab. Please do not disclose the vulnerability before coordinating with us; we will work together to determine a suitable disclosure timeframe.

For more information on how to use the GitHub security tab, please take a look at the official GitHub documentation.

2. The Unikraft Security Team

The Unikraft security team is responsible for a) privately receiving security reports through the GitHub Security feature, b) triaging them, c) coordinating their fixes, as well as d) releasing advisories after (and, if appropriate, during) the fix of the vulnerability.

The security team is currently composed of the following community members:

3. What is Considered a Unikraft Security Vulnerability?

Unikraft is a unikernel: a single protection domain operating system running a single application. This means that, by design, a userland application can freely access and modify the Unikraft kernel memory and control flow. Similarly, system call arguments are not, or only partially, sanitized.

Unikraft supports common security hardening features such as address-space layout randomization, control-flow integrity, or memory tagging. These would typically be applied to both the application and the kernel, and can be enabled to make exploits more difficult by relaxing the claim made in the above paragraph.

What do we consider a Unikraft security vulnerability?

As a rule of thumb, here are classes of bugs which we would consider as security vulnerabilities:

  • Any bug which allows an attacker do bypass or disable security hardening features supported by Unikraft.
  • Any bug in the Unikraft core, in Unikraft libraries, or in non-upstreamed Unikraft-contributed code to third-party projects, that can be triggered from the network, and that can result in availability, confidentiality, or integrity impact.

Based on these guidelines, the Unikraft security team remains responsible to decide whether or not a bug should be considered a Unikraft security vulnerability.

4. Responsible Disclosure

We follow the principles of responsible disclosure. This means:

  • Users first: we will work together with you to establish a suitable disclosure timeframe for the vulnerability. We will treat security reports as a priority.
  • Transparency: after 90 days, security vulnerabilities will be transparently published to the community through GitHub security advisories. In cases where vulnerabilities are particularly complex to address and/or easy to exploit, we may negotiate an extended timeframe with you to ensure the safety of our users is not compromised.

5. Security Q&A

Should I request a CVE identifier for my vulnerability?

Please do not request a CVE identifier. We will handle the assignment of CVE identifiers as part of our triage process, through GitHub Security.

Does the Unikraft project award bounties?

As a community-driven project, we do not award bounties for vulnerability reports; however, if you wish so, we will mention your name and/or pseudonym in our security advisories.

Where are security fixes released?

We release security fixes to the Unikraft staging branch, which regularly transitions to stable. As Unikraft is still in development stages, we do not backport security fixes to older Unikraft releases. However, we maintain a list of disclosed vulnerabilities along with corresponding fix(es) on our security advisories page.

Select a repo