Re: [Xen-devel] Xenstore domains and XS_RESTRICT

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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.

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

Wei.

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