Re: Xenstore domains and XS_RESTRICT

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Wed, Dec 07, 2016 at 08:44:31AM +0100, Juergen Gross wrote:
> Hi,
> 
> today the XS_RESTRICT wire command of Xenstore is supported by
> oxenstored only to drop the privilege of a connection to that of the
> domid given as a parameter to the command.
> 
> Using this mechanism with Xenstore running in a stubdom will lead to
> problems as instead of only a dom0 process dropping its privileges
> the privileges of dom0 will be dropped (all dom0 Xenstore requests
> share the same connection).

.. which means we can't create new XenStore entries or save
off all the XenStore entries?
> 
> In order to solve the problem I suggest the following change to the
> Xenstore wire protocol:
> 
>  struct xsd_sockmsg
>  {
> -    uint32_t type;  /* XS_??? */
> +    uint16_t type;  /* XS_??? */
> +    uint16_t domid; /* Use privileges of this domain */
>      uint32_t req_id;/* Request identifier, echoed in daemon's response.  */
>      uint32_t tx_id; /* Transaction id (0 if not related to a
> transaction). */
>      uint32_t len;   /* Length of data following this. */
> 
>      /* Generally followed by nul-terminated string(s). */
>  };
> 
> domid will normally be zero having the same effect as today.
> 
> Using XS_RESTRICT via a socket connection will run as today by dropping
> the privileges of that connection.
> 
> Using XS_RESTRICT via the kernel (Xenstore domain case) will save the

Xenstore domain case? As in Linux kernel running the XenStore as
an stubdomain?

No, that can't be it. I think you mean that the kernel will have
an priviligied connection all the time?

> domid given as parameter in the connection specific private kernel
> structure. All future Xenstore commands of the connection will have
> this domid set in xsd_sockmsg. The kernel will never forward the
> XS_RESTRICT command to Xenstore.


> 
> A domid other than 0 in xsd_sockmsg will be handled by Xenstore to use
> the privileges of that domain. Specifying a domid in xsd_sockmsg is
> allowed for privileged domain only, of course. XS_RESTRICT via a
> non-socket connection will be rejected in all cases.

Um, but couldn't a malicious guest decide to craft such packet?
> 
> The needed modifications for Xenstore and the kernel are rather small.
> As there is currently no Xenstore domain available supporting
> XS_RESTRICT there are no compatibility issues to expect.
> 
> Thoughts?

I think I need to wrap my head about your use-case? Could you enumerate
what it is?

Thanks.
> 
> 
> Juergen

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