Re: Xenstore domains and XS_RESTRICT

[Juergen Gross <jgross@suse.com>]

On 04/01/17 16:21, Wei Liu wrote:
> On Wed, Jan 04, 2017 at 04:05:03PM +0100, Juergen Gross wrote:
>> 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.
>>
> 
> This highlights the flaw in this command. IMHO it would make sense to
> invent something new other than extending something that is already
> deemed inadequate.

I think this "flaw" is present for any new Xenstore command modifying
the state of a connection for all or some following commands: kernel
and Xen versions are not in sync and so you'd need such mechanisms.

> There is no documentation about the semantics of XS_RESTRICT, which
> is another reason to not touch it.

Yes. See https://lists.xen.org/archives/html/xen-devel/2016-06/msg03487.html


Juergen


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