Re: [Xen-devel] Xenstore domains and XS_RESTRICT

[Juergen Gross <jgross@xxxxxxxx>]

On 07/12/16 15:15, Konrad Rzeszutek Wilk wrote:
> 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?

Example: qemu for domid 4 is dropping its privilege to that of domid 4
with xenstore running as domain (in contrast to xenstored). If we don't
do anything about it dom0 will only be capable to access xenstore with
the privileges domid 4 has (e.g. creation of entries outside of
/local/domain/4/ will be impossible).

>>
>> 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?

Xenstore is running in a stubdom and thus dom0 is issuing xenstore
commands via the kernel (xenbus driver) to the xenstore domain.

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

No. the kernel will have just one connection. Privilege is derived
from domid (dom0 -> 0).

>> 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?

There is no socket connection to xenstore domain.

>>
>> 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?

Xenstore isn't running as a daemon in dom0, but as a domain. All domains
including dom0 have to connect via xenbus. This means all agents in dom0
accessing xenstore share one connection.

In case xenstore is a daemon in dom0 each agent in dom0 accessing
xenstore will open an own socket connection to the daemon, so they can
drop their privileges independent from each other.


Juergen

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