The organization is requesting permission to limit disclosures to only the most severe bugs.
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.
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
