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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.08.16 at 18:28, <ian.jackson@xxxxxxxxxxxxx> wrote:
> 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).

Ah, okay, I think I finally understand. I'm sorry for being dense.

I'm having, however, a hard time imagining a class 2 bug for any
of the hvmop-s that are being converted by the hvmctl series:
These act on the target domain, so would not touch the calling
ones state other than for copying argument structures to/from
guest memory (and I don't view mixing up domain pointers as
a likely source of problems). Any other problem they might
reasonably have would then affect the system as a whole (class
1) or just the target domain (non-security bug).

Jan


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