Xen Project asks to limit security vulnerability advisories
The Xen Project has requested feedback from the community in thrashing out new disclosure guidelines which may only reveal the most serious vulnerabilities affecting the hypervisor.
The Xen Project is a group which brings together developers from the open-source community for the purpose of the Xen Project hypervisor, microkernel-based software which allows users to utilize vitualization technologies.
As with any software, bugs and vulnerabilities will emerge during development.
However, when this occurs, simply fixing the problem is not the end of the issue -- advisories need to be issued and users made aware of any potential threats or exploits.
The non-profit, led by the Linux Foundation, requested feedback this week from the community, asking if it was truly necessary to disclose every bug or flaw found.
Disclosures cost time; time for the security team to create and deploy advisories, downstream time to apply, build and test patches, and the time of users to decide whether to deploy these updates.
The Xen Project Security team is asking whether it really is worth it if a bug has no true real-world impact, such as the loss of customer data or remote attacks.
"The Xen Security Response Process only mentions "'vulnerabilities", without specifying what constitutes a vulnerability," the team says. "We would like guidelines from the community about what sorts of issues should be considered security issues (and thus will have advisories issued)."
Project member George Dunlap is asking the community to consider some tweaks to the Xen Project's security policy. The two major changes are below:
- Leaking of mundane information from Xen or dom0 will not be considered a security issue unless it may contain sensitive guest or user data.
- If no operating systems are vulnerable to a bug, no advisory will be issued.
The sources and target pairs below will be considered important for vulnerability disclosures under the new guidelines:
- The source is the guest userspace, guest kernel, or QEMU stubdomain, and the target is the hypervisor, dom0 and toolstack.
- The source is the guest userspace, guest kernel, or QEMU stubdomain, and the target is another guest.
- The source is guest userspace, and the target is the guest kernel, or other guest userspace processes.
More from RSA 2018
- IBM launches open-source library for securing AI systems
- Fortinet Security Fabric merges with IBM Threat Management system
- Mobile apps transmit unencrypted user data due to insecure SDKs
- Microsoft, Facebook, dozens more sign Cybersecurity Tech Accord
- Intel debuts security solutions at the silicon level
Privilege escalation flaws, denial-of-service attacks which cause services to combust or degrade performance in a significant way, and information leaks will all be considered vulnerabilities. However, if a bug allows a guest kernel to perform a DoS on itself, for example, this will not be considered a vulnerability that is worth issuing an advisory for.
In addition, the security team only wants to issue advisories for certain configurations and exclude others, such as those listed as "experimental" or "tech preview."
Community members who wish to weigh in on the proposed changes have until 28 February.
In 2016, Qualcomm joined the Xen Project Advisory Board to "to accelerate ARM-server and hyperscale cloud development" by promoting the Xen Project and providing financial backup to the scheme.