Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu 
depriv)"):
> On 04.08.16 at 13:21, <ian.jackson@xxxxxxxxxxxxx> wrote:
> > What we cannot do is audit every HVMCTL, fix the class 2 problems, and
> > then declare HVMCTL to have the relevant security property, and
> > implement corresponding code in dom0's privcmd drivers which relies on
> > the security property.  This is because the dom0 privcmd driver
> > doesn't know whether the HVMCTLs it is allowing not-fully-trusted
> > userspace to make are actually trustworthy (with the specific
> > hypervisor version in question.)
> 
> I continue to not really understand this argumentation: Dom0's
> privcmd driver doesn't really matter here. If there's a bug in
> something qemu uses, this is a problem no matter whether that
> operation gets called though the to-be-added privcmd logic, or
> straight from a stubdom qemu. Both are less than fully privileged.
> What do I continue to be missing?

Let me try again.  Earlier I wrote:

  AFAICT there are two kinds of possible bug:

  1. An HVMCTL (or hvmop) that can have an adverse affect on the whole
  system.  Such bugs would already be security bugs, covered by our
  security support policy.  Such a bug would be a security bug whether
  the operation is an hvmop or an HVMCTL or a DMOP.

  2. An HVMCTL (or hvmop) that can have an adverse effect on the calling
  domain.  Such bugs are not currently security bugs.  But the of qemu
  depriv project requires them to be removed.  Such such a bug is a
  security bug if it is a DMOP[1] but not otherwise.

Bugs of class 1 are already security bugs.  They can already be
exploited by stub device models.

Bugs of class 2 are only security bugs if we allow unprivileged
callers within a privileged domain to use the corresponding hypercall.

That is, a bug of class 2 would allow the unprivileged qemu process in
dom0 to cause damage to other parts of dom0.

Bugs of class 2 are of no interest to an attacker who has control of a
stub device model, because all it allows them to do is damage the
device domain domain (which they already control).

Ian.

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