[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Notes for Design Session: Loose ends for becoming a CNA (CVE Numbering Authorities) and other Security Team Operational Questions

Hi all,

on the following topic in session http://sched.co/AjHl we discussed the 
following issues
Here are my notes

* Julien Grall/Stefano Stabellini
* Andrew Cooper
* Ian Jackson
* Lars Kurth
* Security team members


= Consolidate Security Coverage Documents for CNA =

Consolidate security coverage documents where possible (we have a proposal). 

== Review the proposal ==

The ghist is to
* Replace https://wiki.xenproject.org/wiki/Xen_Project_Release_Features, 
xen.git:docs/misc/qemu-xen-security and some other sources with a SUPPORT file 
in some form of mark-up in xen.git trees (starting with master and back-porting 
to security supported trees)
* Link to all relevant pages from https://xenproject.org/security-policy.html 

This has been agreed in principle

== Review the security scope of Features == 

Note that this google doc has taken information from 
xen.git:docs/misc/qemu-xen-security and some other sources as prep work for 
consolidation. Some areas were unclear and required discussion.

We discussed and resolved some of the categorisation in preparation for a full 
proposal on xen-devel. 

IMPORTANT: the attached google docs are *not a proposal*. They are preparation 
for a *formal proposal* on xen-devel@ in future. No final decisions were being 
made at the summit. The discussion at the summit was intended to resolve thorny 
issues *before* making a formal proposal on xen-devel@, making use of key 
people being in one room. The idea is to save time, for what could otherwise be 
a lengthy debate on xen-devel@ by creating maximum alignment upfront. 

We made good progress, BUT there were a few areas to were to tough to resolve
* The question of how to handle limits => we agreed that we would provide 
security support for maximum theoretical limits (we already do), but wanted to 
better set expectations for what we actually test in general, because we expect 
that Xen consumers will use the proposed SUPPORT file outside security support 
* We agreed a new "Obsolete" status, which needs to be encoded (the agreement 
would be to treat it like Deprecated without Security support)
* The ARM area needs a wholesale review, as it does not make much sense

* Julien Grall/Stefano Stabellini: Get the ARM/* items in the list into a 
sensible shape 
* Andrew Cooper: Make a concrete proposal on limits (either now, or once the 
* Ian Jackson: Develop a script that takes the google doc and translates it 
into an appropriate text file to be included in each Xen tree (starting from 
master) and post on xen-devel@ for community review

Once we have agreement, we basically just need to document the outcome, publish 
it and get the process started.

= Other Operational Issues =

== Automated checking of XSA patch levels against releases ==

The problem with the script is that it currently relies on xsa.git that only is 
accessible to security team members

Lars walked through the script and explained how it worked: this was well 
We agreed to include running of the script into the Release Manager checklist

This script currently has a number of issues
a) It relies on a file that can only be generated by the security team which is 
run on xsa.git (a private repository)

The file format is:
xsa-number<tab>patch-path<tab><tab>patch commit message<newline>

210     xsa210.patch            arm/p2m: remove the page from p2m->pages list 
before freeing it
211     xsa211-qemut.patch              cirrus/vnc: zap drop bitblit support 
from console code.
211     xsa211-qemut-4.5.patch          cirrus/vnc: zap drop bitblit support 
from console code.
211     xsa211-qemuu.patch              cirrus/vnc: zap bitblit support from 
console code.

Attached a complete example at the end of the mail. It should be possible to 
generate the file from
* generate the file from http://xenbits.xenproject.org/xsa/
* publish such a file on http://xenbits.xenproject.org/xsa/
* update the tool such that it reads http://xenbits.xenproject.org/xsa/ 

Note that the tool or mechanism should be changed to generate a file based on a 
start-date, not an XSA number as currently done

b) It relies on xsa.git to be checked out
Note that "--xsadir https://xenbits.xenproject.org/xsa"; should work assuming 
that read_file() from File::Read can open files with an http address
I have not tested this

ACTION: Lars to work with Julien/Wei on inclusion of tool into Release Manager 
ACTION: Lars to gather community feedback (as the tool is potentially useful 
for patch management for Xen users)

Ian noted that the tool should be able to run against xsa.git, as well as 
https://xenbits.xenproject.org/xsa as there could be discrepancies between the 
two (e.g. forgotten publication of changes to XSAs)

== Usage of RT and issues that has caused => does it work, what to change? ==
This was an internal discussion and we decided to change the way we use the 
ticketing system
For now, we will only route mails to 
predisclosure-applications@lists.xenproject<dot>org to the RT ticketing system 
until we understand the workflow implications better
Then we will consider at some later point whether to route security@ mails to RT

= Possible/Proposed Process Changes? =

== Bundling of issues / once every other week or monthly XSA publication ==

Two issues were discussed:

a) Currently the security team does sometimes batch XSAs
A disclosure list member raised with Lars in private that this breaks the 
security policy
Security team members believe this is not the case

Having checked the relevant section in 

Quote from the process:
Embargo and disclosure schedule

As discussed, we will negotiate with discoverers about disclosure schedule. Our 
usual starting point for that negotiation, unless there are reasons to diverge 
from this, would be:

* One working week between notification arriving at security@xenproject and the 
issue of our own advisory to our predisclosure list. We will use this time to 
gather information and prepare our advisory, including required patches.

* Two working weeks between issue of our advisory to our predisclosure list and 

When a discoverer reports a problem to us and requests longer delays than we 
would consider ideal, we will honour such a request if reasonable. If a 
discoverer wants an accelerated disclosure compared to what we would prefer, we 
naturally do not have the power to insist that a discoverer waits for us to be 
ready and will honour the date specified by the discoverer.

Naturally, if a vulnerability is being exploited in the wild we will make 
immediately public release of the advisory and patch(es) and expect others to 
do likewise.

Indeed it seems to be the case that this section could be improved with regards 
to bundling (unless I missed a section elsewhere). The sticking point is 
"unless there are reasons to diverge from this". When we cover the "reasons" we 
do not mention bundling explicitly. Maybe it should be mentioned specifically 
in the block "When a discoverer reports a problem to us ... honour the date 
specified by the discoverer".

There was also a discussion as to what other FOSS security teams do. We had a 
member of another (non-Xen Project) security team member present at the 
discussion, who highlighted that other FOSS security teams struggle 
significantly with fixing security issues in a reasonable time frame. Much more 
so than the Xen Project Security Team, with security issues often taking many 
weeks (sometimes several months) until a patch is available.
b) Pending process improvement proposal
See http://markmail.org/message/kxfg5mxw2jvqnmj5
This proposal has been stuck based on lack of feedback, mixed messages and lack 
of the original proposer following up on the proposal. 

A number of specific concerns have been raised:
* The current process is a finely balanced compromise and changes in this area 
are potentially risky 
* We do not currently know whether a monthly release of XSAs would create 
problems for Xen users on the pre-disclosure list (there seem to be mixed 
messages and there is insufficient feedback)
* Several potential sticking points for a fixed-date XSA publication were 
raised, in particular around the risk of information leakage of embargoed 

a) If we pre-disclose XSAs when ready with a publication date (say once a 
month) we would essentially provide longer than 2 weeks embargoes in some 
cases. The project already has relatively long embargo periods compared to 
other projects. The risk of (accidental) information leakage of embargoed 
information by a disclosure list member during embargo increases significantly 
in this scenario
b) The alternative would be for the security team to fix issues in private and 
bundle as we already do and pre-disclose 2 weeks before a fixed monthly embargo 
date. The effect would be that 
b.1) information leakage is reduced as confined to the security team only
b.2) but Xen consumers may be overwhelmed as they have to assess, prepare (in 
particular this applies to preparation of live patches which are more time 
consuming), test, deploy, ... a higher volume of issues in a 2-week disclosure 
period before a fixed publication date

Generally, the consensus was that this is not necessarily a bad proposal, but 
that implications are not understood due to lack of engagement from users. In 
other words: we don't know whether there is a real problem and whether a change 
would solve the underlying problem and whether there would be unintended 
negative consequences. In absence of getting more engagement and information, 
we would not want to drive such a proposal ourselves.

ACTION: Security team members to chip into the discussion and see whether it is 
picked up and we get more feedback

== Include maintainers on pre-disclosure (or before) when affected and not on 
security team ==

In some areas (e.g. QEMU or ARM) we have not included maintainers when fixing 
issues in XSAs: this has led to a recent example where there was a need to 
change a patch post-publication. Most of the time, this is not an issue, as the 
relevant maintainers are also on the security team. 

In the ARM area, we felt that either Julien Grall or Stefano Stabellini should 
become Security team members. 

ACTION: Julien Grall and Stefano Stabellini to discuss whether they would be 
willing to step up

The agreement was that we would update the internal checklist and treat 
maintainers affected by an XSA similar to hardware vendors, which need to be 
pulled in on an as-needed basis for some. Security team members felt this 
requires no process changes.

Relevant section in https://xenproject.org/security-policy.html:
Specific process
3) Furthermore, also in parallel:
* We will determine which systems/configurations/versions are vulnerable, and 
what the impact of the vulnerability is. Depending on the nature of the 
vulnerability this may involve sharing information about the vulnerability (in 
confidence, if the issue is embargoed) with hardware vendors and/or other 
software projects.

Although maybe we should change:

  Depending on the nature of the vulnerability this may involve sharing 
  information about the vulnerability (in confidence, if the issue is 
  embargoed) with hardware vendors and/or other software projects.


  embargoed) with hardware vendors and/or other software projects
  and/or relevant Xen Project maintainers.

The existing section is quite specific and it maybe better to add maintainers 
such that we do not open ourselves to criticism. Alternatively, we could make 
the process less specific.

= Example Files =

Attachment: xsa-210
Description: Binary data

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.