Re: [Xen-devel] Security support scope (apropos of Xen and CNA)
> On 8 May 2017, at 17:11, Andrew Cooper wrote:
>
> On 08/05/17 17:04, Ian Jackson wrote:
>> Tim Deegan writes ("Re: Security support scope (apropos of Xen and CNA)"):
>>> Ah, so it is. So there is information on the wiki page that's not in
>>> MAINTAINERS. Could that be moved into MAINTAINERS? There are
>>> a few things that don't map well to maintainership of specific
>>> files, e.g. "vMCE" or nested virtualization. But on the whole I
>>> think that adding clauses for them would be OK.
>> I think this is quite awkward, really. MAINTAINERS is about files,
>> and implementations. The security support status is about parts of
>> interfaces, which don't map at all well.
>>
>> We could add no-files stanzas, but how would you tell what they
>> referred to ?
>
> This is the principle behind introducing docs/features/* which, as part
> of the required metadata, contains a support statement.
>
> This way, there is an authoritative statement of support on a
> per-feature basis which is easy to keep up to date.
>
> Lars: Any update on your project level clarifications of support statuses?
No, there is no vendor agreement yet on the testing side (aka what testing they
commit to and what would happen if 3rd party testing outside of OSSTEST does
not take place). That and what to do with "security supported" components which
have poor testing for historical reasons are the only outstanding issue. These
are really big issues, where there is no real consensus. I will get a Design
Session in place for this at the summit: maybe we can make some progress.
However, IMHO, we can start off agreeing a format: in nutshell what we need is
a list that shows feature=status - although we may want to add a few more
fields, aka feature=(support status=..., maintainer status=, tested=OSSTEST|XTF|3rd Party|..., ...). Someone needs to make a sensible
proposal.
For example, we could just map "status" on what we have now: preview,
experimental, supported (which includes security support) and extend/change the
meaning of the status field as this gets resolved. I don't think the two things
are strongly linked.
Lars
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Security support scope (apropos of Xen and CNA)
On 08/05/17 17:04, Ian Jackson wrote:
> Tim Deegan writes ("Re: Security support scope (apropos of Xen and CNA)"):
>> Ah, so it is. So there is information on the wiki page that's not in
>> MAINTAINERS. Could that be moved into MAINTAINERS? There are
>> a few things that don't map well to maintainership of specific
>> files, e.g. "vMCE" or nested virtualization. But on the whole I
>> think that adding clauses for them would be OK.
> I think this is quite awkward, really. MAINTAINERS is about files,
> and implementations. The security support status is about parts of
> interfaces, which don't map at all well.
>
> We could add no-files stanzas, but how would you tell what they
> referred to ?
This is the principle behind introducing docs/features/* which, as part
of the required metadata, contains a support statement.
This way, there is an authoritative statement of support on a
per-feature basis which is easy to keep up to date.
Lars: Any update on your project level clarifications of support statuses?
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Security support scope (apropos of Xen and CNA)
Tim Deegan writes ("Re: Security support scope (apropos of Xen and CNA)"):
> Ah, so it is. So there is information on the wiki page that's not in
> MAINTAINERS. Could that be moved into MAINTAINERS? There are
> a few things that don't map well to maintainership of specific
> files, e.g. "vMCE" or nested virtualization. But on the whole I
> think that adding clauses for them would be OK.
I think this is quite awkward, really. MAINTAINERS is about files,
and implementations. The security support status is about parts of
interfaces, which don't map at all well.
We could add no-files stanzas, but how would you tell what they
referred to ?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Security support scope (apropos of Xen and CNA)
Hi, At 09:59 +0100 on 05 May (1493978382), Lars Kurth wrote: > > On 5 May 2017, at 09:43, Tim Deegan wrote: > > - Only features listed as Supported in MAINTAINERS get support. > > This seems related to George's proposal of the scope. I am not sure > MAINTAINERS is correct though (e.g. live-patching is probably listed as > Supported but does not get security support) > Ah, so it is. So there is information on the wiki page that's not in MAINTAINERS. Could that be moved into MAINTAINERS? There are a few things that don't map well to maintainership of specific files, e.g. "vMCE" or nested virtualization. But on the whole I think that adding clauses for them would be OK. Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Security support scope (apropos of Xen and CNA)
> On 5 May 2017, at 09:43, Tim Deegan wrote: > > At 13:53 +0100 on 04 May (1493905990), Ian Jackson wrote: >> To become a CNA (CVE Numbering Authority), which we would like to do, >> we need to provide MITRE's CNA programme with a definition of the >> scope of our CNA. That should be the scope of our general security >> support, clearly. >> >> At the moment we don't seem to have this written down in a single >> clear document. I am aware of the following places which can contain >> information about security support (normally, in the form of >> statements saying that certain things are not supported): >> >> * https://wiki.xenproject.org/wiki/Xen_Project_Release_Features has a >> table of versions with security support, and information about some >> features. >> >> * xen.git:docs/misc/qemu-xen-security, limits security support to >> some configurations. >> >> * xen.git:MAINTAINERS might in principle have a status not implying >> security support. >> >> * Docs for an individual feature (eg in xl docs) might say that the >> feature is not advised, or not supported, or something. >> >> * Previous XSA advisories might withdraw support. >> >> This diversity of information sources is rather unsatisfactory. >> >> I think we need to at least reduce the number of different information >> sources. Also we need an overview document which points to them all. >> >> Where should this overview document be ? Which of the above sources >> should be coalesced into which others ? > > IMO the overview should on the main xenproject.org site, ideally in > the security process preamble, or beside it if it gets too long. I am happy with that > It should read something like this: > > - Security support is provided for the following versions: > [List of versions, + an item on the release checklist to update it.] A bit more work, but can be done > - Only features listed as Supported in MAINTAINERS get support. This seems related to George's proposal of the scope. I am not sure MAINTAINERS is correct though (e.g. live-patching is probably listed as Supported but does not get security support) > - Specific exemptions: > [ move qemu-xen-security here, and delete it from the tree ] > [ brief summary of XSA-77 + a link for details. ] > [ anything else? I don't think we need to explicitly call out to > docs for individual features, but there might be some things > to mention here, e.g. DMA attacks with IOMMU disabled. ] > > Not sure about the Xen_Project_Release_Features wiki page -- it's nice > to have all that info + historical versions in one place; on the > other hand it's not the canonical source for most of it and risks > getting out of date. Maybe it needs an introduction pointing out > that MAINTAINERS and the new security scope doc are the official sources. Also everyone can edit it. To be honest, if we need to make changes frequently, we should probably maintain this in-tree. Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Security support scope (apropos of Xen and CNA)
At 13:53 +0100 on 04 May (1493905990), Ian Jackson wrote: > To become a CNA (CVE Numbering Authority), which we would like to do, > we need to provide MITRE's CNA programme with a definition of the > scope of our CNA. That should be the scope of our general security > support, clearly. > > At the moment we don't seem to have this written down in a single > clear document. I am aware of the following places which can contain > information about security support (normally, in the form of > statements saying that certain things are not supported): > > * https://wiki.xenproject.org/wiki/Xen_Project_Release_Features has a >table of versions with security support, and information about some >features. > > * xen.git:docs/misc/qemu-xen-security, limits security support to >some configurations. > > * xen.git:MAINTAINERS might in principle have a status not implying >security support. > > * Docs for an individual feature (eg in xl docs) might say that the >feature is not advised, or not supported, or something. > > * Previous XSA advisories might withdraw support. > > This diversity of information sources is rather unsatisfactory. > > I think we need to at least reduce the number of different information > sources. Also we need an overview document which points to them all. > > Where should this overview document be ? Which of the above sources > should be coalesced into which others ? IMO the overview should on the main xenproject.org site, ideally in the security process preamble, or beside it if it gets too long. It should read something like this: - Security support is provided for the following versions: [List of versions, + an item on the release checklist to update it.] - Only features listed as Supported in MAINTAINERS get support. - Specific exemptions: [ move qemu-xen-security here, and delete it from the tree ] [ brief summary of XSA-77 + a link for details. ] [ anything else? I don't think we need to explicitly call out to docs for individual features, but there might be some things to mention here, e.g. DMA attacks with IOMMU disabled. ] Not sure about the Xen_Project_Release_Features wiki page -- it's nice to have all that info + historical versions in one place; on the other hand it's not the canonical source for most of it and risks getting out of date. Maybe it needs an introduction pointing out that MAINTAINERS and the new security scope doc are the official sources. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Security support scope (apropos of Xen and CNA)
>>> On 04.05.17 at 14:53, wrote: > To become a CNA (CVE Numbering Authority), which we would like to do, > we need to provide MITRE's CNA programme with a definition of the > scope of our CNA. That should be the scope of our general security > support, clearly. > > At the moment we don't seem to have this written down in a single > clear document. I am aware of the following places which can contain > information about security support (normally, in the form of > statements saying that certain things are not supported): > > * https://wiki.xenproject.org/wiki/Xen_Project_Release_Features has a >table of versions with security support, and information about some >features. > > * xen.git:docs/misc/qemu-xen-security, limits security support to >some configurations. > > * xen.git:MAINTAINERS might in principle have a status not implying >security support. > > * Docs for an individual feature (eg in xl docs) might say that the >feature is not advised, or not supported, or something. > > * Previous XSA advisories might withdraw support. > > This diversity of information sources is rather unsatisfactory. > > I think we need to at least reduce the number of different information > sources. Also we need an overview document which points to them all. > > Where should this overview document be ? Which of the above sources > should be coalesced into which others ? Generally the (or a new) wiki page would seem the best place to me, if only there weren't some pretty fine grained restrictions, like the use of certain command line options rendering the whole thing unsupported. For that specific example, it would seem to me that only the command line doc itself would be a suitable place (and we'd basically have to go through and add a warning for every such option). Bottom line - I'm not sure a single place will do, but of course one central place could/should xref all other places with additional information. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Security support scope (apropos of Xen and CNA)
To become a CNA (CVE Numbering Authority), which we would like to do, we need to provide MITRE's CNA programme with a definition of the scope of our CNA. That should be the scope of our general security support, clearly. At the moment we don't seem to have this written down in a single clear document. I am aware of the following places which can contain information about security support (normally, in the form of statements saying that certain things are not supported): * https://wiki.xenproject.org/wiki/Xen_Project_Release_Features has a table of versions with security support, and information about some features. * xen.git:docs/misc/qemu-xen-security, limits security support to some configurations. * xen.git:MAINTAINERS might in principle have a status not implying security support. * Docs for an individual feature (eg in xl docs) might say that the feature is not advised, or not supported, or something. * Previous XSA advisories might withdraw support. This diversity of information sources is rather unsatisfactory. I think we need to at least reduce the number of different information sources. Also we need an overview document which points to them all. Where should this overview document be ? Which of the above sources should be coalesced into which others ? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
