|
[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 ACTIONS for * Julien Grall/Stefano Stabellini * Andrew Cooper * Ian Jackson * Lars Kurth * Security team members Regards Lars = Consolidate Security Coverage Documents for CNA = Consolidate security coverage documents where possible (we have a proposal). Specifically == Review the proposal == See https://docs.google.com/document/d/17LiK-C3oBFZNpxeihXxkM2Bagn7A2L3Dv1u1ZGZe_TQ/edit 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 == See https://docs.google.com/spreadsheets/d/1wLb37mbxN715rlYD8eKV8htgatDI41noOmQ1H428QX4/edit#gid=0 Note that this google doc has taken information from https://wiki.xenproject.org/wiki/Xen_Project_Release_Features, 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 ACTIONS: * 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 == See https://xenbits.xenproject.org/gitweb/?p=people/larsk/xen-release-scripts.git;a=summary 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 received. 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> Example: 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 checklist 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 https://xenproject.org/security-policy.html: 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 publication. 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 information 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. To ... 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |