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

Re: [Xen-devel] RFC v2: Scope of Vulnerabilities for which XSAs are issued

>>> On 17.02.17 at 11:11, <lars.kurth.xen@xxxxxxxxx> wrote:
>> On 14 Feb 2017, at 17:25, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
>> 1c. The source is guest userspace, and the target is the guest kernel,
>> or other guest userspace processes.
>> This means, for instance, that bug which allows a guest kernel to
>> perform a DoS on itself will not be considered a security
>> vulnerability.  
> Maybe the better way to phrase this is: "will not be considered a Xen 
> security vulnerability." (But presumably it is a vulnerability elsewhere, 
> e.g. Linux, ...)
> Again in this case, we would not issue an XSA, but what would we do?
> Direct the reporter to the appropriate project and/or raise the issue on 
> another project. Clearly in that case, there is a security issue, but it's 
> not Xen specific.

I don't think there's a security issue anywhere in this case: The kernel
shooting itself in the foot certainly is a bug in that kernel, but not a
security issue if it can't be triggered from outside the kernel.

>> It also means, at the moment, that the security team
>> will not issue advisories for highly disaggregated environments.
> I am not sure I fully understand this, because 1b presumably covers 
> disaggregated environments. Also, what would the practical implications be? 
> In particular for downstream such as QubesOS, OpenXT and others ? Is there a 
> single XSA which we have covered in the past, which we would not handle?

As of XSA-77 this has already been our standard procedure for
issues only affecting highly disaggregated environments.


Xen-devel mailing list



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