Tag Archives: security team

Request for Comment: Scope of Vulnerabilities for which XSAs are issued

Issuing advisories has a cost: It costs the security team significant amounts of time to craft and send the advisories; it costs many of our downstreams time to apply, build, and test patches; and it costs many of our users time to decide whether to do an update, and if so, to test and deploy it.

Given this, the Xen Project Security Team wants to clarify when they should issue an advisory or not: the Xen Security Response Process only mentions “‘vulnerabilities”, without specifying what constitutes a vulnerability.

We would like guidelines from the community about what sorts of issues should be considered security issues (and thus will have advisories issued). I have posted the second version a draft of a section I am proposing to be added to the Xen Security Policy to xen-devel; a copy is included below for your convenience. There are only minor modifications from the first draft, so barring major feedback from the wider community it will likely achieve consensus. If you want input, now is the time to speak up.

Most of it is just encoding long-established practice. But there are two key changes and / or clarifications that deserve attention and discussion:

    Criteria 2c: Leaking of mundane information from Xen or dom0 will not be considered a security issue unless it may contain sensitive guest or user data

Criteria 4: If no operating systems are vulnerable to a bug, no advisory will be issued.

If you want to weigh in on the question, please join the discussion on xen-devel before 28 February. The title of the thread is “RFC v2: Scope of Vulnerabilities for which XSAs are issued”.

Continue reading

What You Need to Know about Recent Xen Project Security Advisories

Today the Xen Project announced eight security advisories: XSA-191 to XSA-198. The bulk of these security advisories were discovered and fixed during the hardening phase of the Xen Project Hypervisor 4.8 release (expected to come out in early December). The Xen Project has implemented a security-first approach when publishing new releases.

In order to increase the security of future releases, members of the Xen Project Security Team and key contributors to the Xen Project, actively search and fix security bugs in code areas where vulnerability were found in past releases. The contributors use techniques such as code inspections, static code analysis, and additional testing using fuzzers such as American Fuzzy Lop. These fixes are then backported to older Xen Project releases with security support and published in bulk to make it easier for downstreams consumers to apply security fixes.

Before we declare a new Xen Project feature as supported, we perform a security assessment (see declare the Credit2 scheduler as supported). In addition, the contributors focused on security have started crafting tests for each vulnerability and integrated them into our automated regression testing system run regularly on all maintained versions of Xen. This ensures that the patch will be applied to every version which is vulnerable, and also ensures that no bug is accidentally reintroduced as development continues to go forward.

The Xen Project’s mature and robust security response process is optimized for cloud environments and downstream Xen Project consumers to maximize fairness, effectiveness and transparency. This includes not publicly discussing any details with security implications during our embargo period. This encourages anyone to report bugs they find to the Xen Project Security team, and allows the Xen Project Security team to assess, respond, and prepare patches, before before public disclosure and broad compromise occurs.

During the embargo period, the Xen Project does not publicly discuss any details with security implications except:

  • when co-opting technical assistance from other parties;
  • when issuing a Xen Project Security Advisory (XSA). This is pre-disclosed to only members on the Xen Project Pre-Disclosure List (see www.xenproject.org/security-policy.html); and
  • when necessary to coordinate with other projects affected

The Xen Project security team will assign and publicly release numbers for vulnerabilities. This is the only information that is shared publicly during the embargo period. See this url for “XSA Advisories, Publicly Released or Pre-Released”: xenbits.xen.org/xsa.

Xen’s latest XSA-191, XSA-192, XSA-193, XSA-194, XSA-195, XSA-196, XSA-197 and XSA-198 Advisory can all be found here:
xenbits.xen.org/xsa

Any Xen-based public cloud is eligible to be on our “pre-disclosure” list. Cloud providers on the list were notified of the vulnerability and provided a patch two weeks before the public announcement in order to make sure they all had time to apply the patch to their servers.

Distributions and other major software vendors of Xen Project software were also given the patch in advance to make sure they had updated packages ready to download as soon as the vulnerability was announced. Private clouds and individuals are urged to apply the patch or update their packages as soon as possible.

All of the above XSAs that affect the hypervisor can be deployed using the Xen Project LivePatching functionality, which enables re-boot free deployment of security patches to minimize disruption and downtime during security upgrades for system administrators and DevOps practitioners. The Xen Project encourages its users to download these patches.

More information about the Xen Project’s Security Vulnerability Process, including the embargo and disclosure schedule, policies around embargoed information, information sharing among pre-disclosed list members, a list of pre-disclosure list members, and the application process to join the list, can be found at: www.xenproject.org/security-policy.html

Please Welcome new Members of the Xen Project Hypervisor Leadership Team

Evolution of Hypervisor Git Commits within the project. Note that in in the same time period, the number of individuals and organisations contributing to the project has nearly doubled.

Evolution of Hypervisor Git Commits within the project. Note that in parallel the number of individuals and organisations contributing to the project has nearly doubled.

The Xen Project has experienced incredible growth in our community (see diagram on the right) and simultaneously the Xen Project advisory board has funded a lot of great projects that help support the larger Xen Project ecosystem, for example MirageOS, a library operating system that constructs unikernels for secure, high-performance network applications across a variety of cloud computing and mobile platforms. These projects are extremely important to the expansion and betterment of virtualization and cloud computing infrastructure, but also demand more work to be done by committers and maintainers.

We understood that there was plenty of leadership among the community, but didn’t know the best way to promote contributors to maintainers and committer roles for leadership to the Hypervisor and its interface with Linux.

We decided to introduced a new convention, by which we actively reminded community members to nominate or self-nominate themselves for leadership roles. Often times, active developers simply worked on the project, but did not consider to nominate newcomers (or themselves) for these leadership roles within the project.

We also felt that running the entire nomination process in public, which may include public feedback on a nominee, could discourage people from recommending themselves or recommending others. So we decided to follow the approach that Debian uses for Technical Committee seats, where candidates are nominated in private. A group of the senior leadership for the Xen Project would then review the submissions and provide feedback and acceptance, making the overall process less intimidating.

As for committers and maintainers, we promoted several key Xen Project contributors to these distinguished roles based on previous experience and similar work they had already been performing, but didn’t have the authorship to own. This very important as it will ensure the group of maintainers that we currently have will have the support they need to accommodate for the Xen Project hypervisor.

Through taking the approach of consistent promotion and private forums, we have found some incredible new members to the Xen Project Hypervisor Leadership team that we want to introduce to you.

Committers
The following people have been elected to be new Committers to the project, they will be joining long-time committers Ian Campbell, Ian Jackson, Jan Beulich and Konrad Rzeszutek Wilk:

Andrew Cooper has been working on the Hypervisor since 2011 and has added a number of major new features such as Migration v2, significant change to trap handling, improvements to cpuid handling for guests and many more.

George Dunlap has been working on the Hypervisor since 2005 and was heavily involved in making the tracing system useable for performance analysis, optimising the shadow code, wrote the credit2 scheduler and developed many other significant features and improvements in the hypervisor. In addition, he was our first Release Manager and is leading the CentOS Virtualisation SIG within CentOS.

Stefano Stabellini has been working on the Hypervisor and the Linux Kernel since 2007 and was instrumental in bringing ARM support to the Xen Hypervisor. He has also been leading many other activities within the project, such as the creation of libxenlight, adding support upstream QEMU to Xen, Xen OpenStack integration and Raisin.

Wei Liu started to work on the Xen Project as a GSoC student in 2011 (working in virtio support). He has been working on libxl support, event channel scalability, MiniOS and many other major Xen features. In addition, he has been the Xen Project Release Manager since Xen Project 4.6 release.

Andrew and Wei celebrated their appointment at the Xen Project hackathon last month by submitting and ACKing a piece of code while on a punt on the river Cam in Cambridge, UK.

Security Team
In addition, Andrew Cooper and George Dunlap are now also members of the Xen Project Security Team, alongside Ian Jackson, Jan Beulich, Konrad Rzeszutek Wilk and Tim Deegan.

Maintainers
The following people were also recently added as MAINTAINERS of the project: Doug Goldstein (KConfig, Travis CI), Julien Grall (ARM support, device tree, …), Meng Xu (RTDS Scheduler) and Paul Durrant (x86 I/O emulation, x86 viridian enlightenments, …). In addition, we clarified some ambiguities around the maintainer role.

Linux Kernel Maintainers
Jürgen Gross who has been a Linux kernel and Xen developer since 2004, but has significantly increased his engagement within the community in the last two years, is now Linux Kernel maintainer for the Xen Hypervisor Interface alongside Boris Ostrovsky and David Vrabel. Other maintainers of Xen specific components in the Linux Kernel are Stefano Stabellini, Wei Lui, and Konrad Rzeszutek Wilk.

A couple of months ago two of our committers, Keir Fraser and Tim Deegan, formally stepped down in their roles as committers from the Hypervisor team. We want to thank Keir and Tim for the vast contributions to the project. We look forward to seeing what they work on next and, again, thank them for the success that they brought to the open source Xen hypervisor.

Xen-API Community Project Update

The kickoff meeting for the Xen-API community project is scheduled for May 15, 2008 at 4pm EST. I am still looking for people interested in working on this project and the meeting is open to all Xen.org community members. I will be posting all meeting minutes and activities on the Xen Wiki once the project is underway so attendance at the meetings is not mandatory; however, the first few meetings will be important as we discuss what work items need to be complete and people get a chance to volunteer.

The dial-in information for the meeting is:

US: 1.888.371.8921
Int’l: http://www.btconferencing.com/citrix/globalaccess/
Code: 275279

Xen-API Community Project

Several community members have contacted me recently about the Xen-API utilities. I looked into this and discovered a great opportunity for community members looking for a project to contribute to. So, I am announcing a new community effort to complete the development of the Xen-API utilities. If you are interested in working on the Xen-API project please email me at stephen.spector@xen.org and I will call a meeting in mid-May with all people interested to get the project underway.

NOTE – This interface is not to be seen as a replacement for the existing XML-RPC interface and people should not infer anything by this project.

Here are some thoughts on the importance of the Xen-API if you are considering joining this community effort:

  • Xen-API cleans up a lot of the cruft of the older APIs
  • Authentication aspect to the Xen-API allows the API to be used off-box securely
  • Xen-API’s event registration / dispatch piece is much better than the old API, making it much easier to build web GUIs or health monitors
  • The Xen-API has two mechanisms, one for synchronous task invocation, and a congruent one for asynchronous tasks. This means, for example, that you can reboot a VM, and either block waiting for it to complete, or get a task handle and poll back later. This gives application developers the freedom to choose how they interact with Xend
  • Xend will get a code update from this project and will give developers a chance to learn more about xm as well as Xend (Xend is written in Python)
  • Xen-API already has C and Python bindings in the Xen tree; Ruby bindings are also rumored to exist

Available information on Xen-API: