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

Re: [Xen-devel] [PATCH] SUPPORT.md: Clarify stubdomain support


  • To: Wei Liu <wei.liu2@xxxxxxxxxx>
  • From: George Dunlap <george.dunlap@xxxxxxxxxx>
  • Date: Tue, 25 Sep 2018 11:39:37 +0100
  • Autocrypt: addr=george.dunlap@xxxxxxxxxx; prefer-encrypt=mutual; keydata= xsFNBFPqG+MBEACwPYTQpHepyshcufo0dVmqxDo917iWPslB8lauFxVf4WZtGvQSsKStHJSj 92Qkxp4CH2DwudI8qpVbnWCXsZxodDWac9c3PordLwz5/XL41LevEoM3NWRm5TNgJ3ckPA+J K5OfSK04QtmwSHFP3G/SXDJpGs+oDJgASta2AOl9vPV+t3xG6xyfa2NMGn9wmEvvVMD44Z7R W3RhZPn/NEZ5gaJhIUMgTChGwwWDOX0YPY19vcy5fT4bTIxvoZsLOkLSGoZb/jHIzkAAznug Q7PPeZJ1kXpbW9EHHaUHiCD9C87dMyty0N3TmWfp0VvBCaw32yFtM9jUgB7UVneoZUMUKeHA fgIXhJ7I7JFmw3J0PjGLxCLHf2Q5JOD8jeEXpdxugqF7B/fWYYmyIgwKutiGZeoPhl9c/7RE Bf6f9Qv4AtQoJwtLw6+5pDXsTD5q/GwhPjt7ohF7aQZTMMHhZuS52/izKhDzIufl6uiqUBge 0lqG+/ViLKwCkxHDREuSUTtfjRc9/AoAt2V2HOfgKORSCjFC1eI0+8UMxlfdq2z1AAchinU0 eSkRpX2An3CPEjgGFmu2Je4a/R/Kd6nGU8AFaE8ta0oq5BSFDRYdcKchw4TSxetkG6iUtqOO ZFS7VAdF00eqFJNQpi6IUQryhnrOByw+zSobqlOPUO7XC5fjnwARAQABzSRHZW9yZ2UgVy4g RHVubGFwIDxkdW5sYXBnQHVtaWNoLmVkdT7CwYAEEwEKACoCGwMFCwkIBwMFFQoJCAsFFgID AQACHgECF4ACGQEFAlpk2IEFCQo9I54ACgkQpjY8MQWQtG1A1BAAnc0oX3+M/jyv4j/ESJTO U2JhuWUWV6NFuzU10pUmMqpgQtiVEVU2QbCvTcZS1U/S6bqAUoiWQreDMSSgGH3a3BmRNi8n HKtarJqyK81aERM2HrjYkC1ZlRYG+jS8oWzzQrCQiTwn3eFLJrHjqowTbwahoiMw/nJ+OrZO /VXLfNeaxA5GF6emwgbpshwaUtESQ/MC5hFAFmUBZKAxp9CXG2ZhTP6ROV4fwhpnHaz8z+BT NQz8YwA4gkmFJbDUA9I0Cm9D/EZscrCGMeaVvcyldbMhWS+aH8nbqv6brhgbJEQS22eKCZDD J/ng5ea25QnS0fqu3bMrH39tDqeh7rVnt8Yu/YgOwc3XmgzmAhIDyzSinYEWJ1FkOVpIbGl9 uR6seRsfJmUK84KCScjkBhMKTOixWgNEQ/zTcLUsfTh6KQdLTn083Q5aFxWOIal2hiy9UyqR VQydowXy4Xx58rqvZjuYzdGDdAUlZ+D2O3Jp28ez5SikA/ZaaoGI9S1VWvQsQdzNfD2D+xfL qfd9yv7gko9eTJzv5zFr2MedtRb/nCrMTnvLkwNX4abB5+19JGneeRU4jy7yDYAhUXcI/waS /hHioT9MOjMh+DoLCgeZJYaOcgQdORY/IclLiLq4yFnG+4Ocft8igp79dbYYHkAkmC9te/2x Kq9nEd0Hg288EO/OwE0EVFq6vQEIAO2idItaUEplEemV2Q9mBA8YmtgckdLmaE0uzdDWL9To 1PL+qdNe7tBXKOfkKI7v32fe0nB4aecRlQJOZMWQRQ0+KLyXdJyHkq9221sHzcxsdcGs7X3c 17ep9zASq+wIYqAdZvr7pN9a3nVHZ4W7bzezuNDAvn4EpOf/o0RsWNyDlT6KECs1DuzOdRqD oOMJfYmtx9hMzqBoTdr6U20/KgnC/dmWWcJAUZXaAFp+3NYRCkk7k939VaUpoY519CeLrymd Vdke66KCiWBQXMkgtMGvGk5gLQLy4H3KXvpXoDrYKgysy7jeOccxI8owoiOdtbfM8TTDyWPR Ygjzb9LApA8AEQEAAcLBZQQYAQoADwIbDAUCWmTXMwUJB+tP9gAKCRCmNjwxBZC0bb+2D/9h jn1k5WcRHlu19WGuH6q0Kgm1LRT7PnnSz904igHNElMB5a7wRjw5kdNwU3sRm2nnmHeOJH8k Yj2Hn1QgX5SqQsysWTHWOEseGeoXydx9zZZkt3oQJM+9NV1VjK0bOXwqhiQyEUWz5/9l467F S/k4FJ5CHNRumvhLa0l2HEEu5pxq463HQZHDt4YE/9Y74eXOnYCB4nrYxQD/GSXEZvWryEWr eDoaFqzq1TKtzHhFgQG7yFUEepxLRUUtYsEpT6Rks2l4LCqG3hVD0URFIiTyuxJx3VC2Ta4L H3hxQtiaIpuXqq2D4z63h6vCx2wxfZc/WRHGbr4NAlB81l35Q/UHyMocVuYLj0llF0rwU4Aj iKZ5qWNSEdvEpL43fTvZYxQhDCjQTKbb38omu5P4kOf1HT7s+kmQKRtiLBlqHzK17D4K/180 ADw7a3gnmr5RumcZP3NGSSZA6jP5vNqQpNu4gqrPFWNQKQcW8HBiYFgq6SoLQQWbRxJDHvTR YJ2ms7oCe870gh4D1wFFqTLeyXiVqjddENGNaP8ZlCDw6EU82N8Bn5LXKjR1GWo2UK3CjrkH pTt3YYZvrhS2MO2EYEcWjyu6LALF/lS6z6LKeQZ+t9AdQUcILlrx9IxqXv6GvAoBLJY1jjGB q+/kRPrWXpoaQn7FXWGfMqU+NkY9enyrlw==
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Konrad Wilk <konrad.wilk@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 25 Sep 2018 10:39:45 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Openpgp: preference=signencrypt

On 03/06/2018 07:05 PM, Wei Liu wrote:
> On Tue, Mar 06, 2018 at 06:18:12PM +0000, George Dunlap wrote:
>> On 03/06/2018 06:08 PM, Wei Liu wrote:
>>> On Tue, Mar 06, 2018 at 05:08:43PM +0000, George Dunlap wrote:
>>>> We don't promise to protect you against rogue stub domain binaries;
>>>> only from the running domain once the guest has come up.
>>>>
>>>> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
>>>> ---
>>>> CC: Ian Jackson <ian.jackson@xxxxxxxxxx>
>>>> CC: Wei Liu <wei.liu2@xxxxxxxxxx>
>>>> CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> CC: Jan Beulich <jbeulich@xxxxxxxx>
>>>> CC: Tim Deegan <tim@xxxxxxx>
>>>> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>>>> CC: Konrad Wilk <konrad.wilk@xxxxxxxxxx>
>>>> CC: Julien Grall <julien.grall@xxxxxxx>
>>>> ---
>>>>  SUPPORT.md | 5 +++++
>>>>  1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/SUPPORT.md b/SUPPORT.md
>>>> index a1810b8046..ce9f68e1c2 100644
>>>> --- a/SUPPORT.md
>>>> +++ b/SUPPORT.md
>>>> @@ -501,6 +501,11 @@ for more information about security support.
>>>>  
>>>>      Status: Supported, with caveats
>>>>  
>>>> +Only stub domain binaries provided by the host admin
>>>> +or trusted users are security supported;
>>>
>>> I'm not sure I follow -- why would / should upstream support a binary
>>> that is not produced from upstream source code?
>>
>> Hrm, seems I wasn't very clear.
>>
>> Suppose for some reason, a cloud provider says to their customers, "I'll
>> let you submit *your own* devicemodel binary!  Your virtual guests can
>> have whatever virtual hardware you can code up!  It's secure because it
>> runs as a stub domain!"
>>
>> And suppose that we discover a bug in the stubdomain setup code, that
>> would allow a "crafted image" to break into the toolstack; or we
>> discovered a bug such that a rogue stubdomain could cause problems after
>> the stubdomain started but before the guest started.  Should we issue an
>> XSA in that case?
>>
>> The point of this statement is to say, "No, we would not issue an XSA in
>> that case: We only provide security support for systems where the
>> administrator or trusted users provide the stub domain binary; the stub
>> domain is only meant to protect against attacks *after* the VM has
>> started up."
>>
> 
> I think there is too much special-casing here. Stubdom is just another
> domain. It should be treated like any untrusted DomU, unless there is
> some set of interfaces which is only available to stubdom but not an
> ordinary DomU. In this case -- the toolstack code that sets up the
> stubdom? Some special xenstore node that only stubdom can read from /
> write to?

[Reviving this thread after ages]

I think my answer before contains the answer to your question.  Yes, a
stubdomain *image* has access to code and interfaces that a *running
stubdomain* does not -- it interacts with the setup code.  Its image is
parsed by the toolstack, which means that a *hostile image* has
opportunities to break into the toolstack that a *hostile running
domain* (i.e., one which became hostile as a result of being exploited)
does not).  In addition, stub domains starts running before the
toolstack is completely finished setting up the target VM; if there were
a race condition somewhere in the setup code, a rogue stubdomain could
potentially take advantage of this race condition.

This didn't come out of nowhere.  From the Security Team's perspective,
the main purpose of SUPPORT.md is to be able to say of a bug, "This is
not a security issue; we will not issue an XSA."  There was specifically
an issue for which we didn't want to issue an XSA because it's a
configuration nobody ever intended on supporting, hence the patch.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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