Re: [Xen-devel] RFC: Adding a section to the Xen security policy about what constitutes a vulnerability

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Jan 04, 2017 at 12:43:02PM +0000, George Dunlap wrote:
> On Wed, Jan 4, 2017 at 12:36 PM, George Dunlap <george.dunlap@xxxxxxxxxx> 
> wrote:
> > 4. The security team will only issue an advisory if there is a known
> > combination of software in which the vulnerability can be exploited.
> >
> > In most cases, the software which contains the bug is also the target
> > of the attack: that is, a bug in Xen allows an unprivileged user to
> > crash Xen, a bug in QEMU allows an unprivileged user to escalate its
> > privileges to that of the QEMU process.  In these cases "using Xen" or
> > "using QEMU" imples "being vulnerable".
> >
> > But this is not always so: for instance, a bug in the Xen instruction
> > emulator might allow a guest user to attack the guest kernel, *if* the
> > guest kernel behaves in a certain way, but not if it behaves in other
> > ways.  In such a case, a bug will only be considered a vulnerability
> > if there are known operating systems on which the attack can be
> > executed.  If no operating system can be found which allows such an
> > attack, no advisory will be issued.
> >
> > If a bug requires a vulnerable operating system to be exploitable, the
> > Xen Security Team will pro-actively investigate the vulnerability of
> > the following open-source operating systems: Linux, OpenBSD, FreeBSD,
> > and NetBSD.  The security team may also test or otherwise investigate
> > the vulnerability of some proprietary operating systems.
> >
> > (An example of this scenario is XSA-176: There was a bug in the
> > handling of the pagetable PS bits for L3 and L4; but no known
> > operating systems were vulnerable to an exploit as a result of the
> > bug.  Under these guidelines, XSA-176 would not have been issued.)
> 
> One thing to consider: This formulation would also exclude bugs in
> libxl that weren't exploitable under either xl or libvirt (the only
> known toolstacks that link against libxl).  I'm of two minds about
> that restriction; and I'm not immediately sure what promise we would
> make instead.  (Make an exception for libxl, perhaps?  Or specify that
> it's only operating systems for which there must be a known example?)
> 

FWIW I think restricting to known widely used open source toolstack (xl
and libvirt as of writing) is reasonable, given security team has
limited resources.

Wei.

>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> https://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel