[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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |