Re: [Xen-devel] Xenstore domains and XS_RESTRICT

[Juergen Gross <jgross@xxxxxxxx>]

On 04/01/17 15:59, Wei Liu 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).
>>
>> 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
>> 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.
>>
> 
> I'm slightly concerned about this non-unified model -- I would rather
> xenstored only needs to deal with "virtual connection", regardless of
> the interface (socket or kernel) they use.

Rejecting XS_RESTRICT for a non-socket connection is mandatory to
ensure a XS_RESTRICT user on an old kernel not knowing about it can't
drop the privilege of all other user's on that system, too.

> I'm not convinced that socket-based distinction is good enough -- what
> if some program tries to multiplex the socket? Is that not possible at
> the moment?

In this case it would have to handle XS_RESTRICT the same way as the
kernel should do it.


Juergen


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