Re: [Xen-devel] Xenstore domains and XS_RESTRICT

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Wed, Dec 07, 2016 at 03:26:38PM +0100, Juergen Gross wrote:
> 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).

But .. why? Shouldn't it have RWX access to its tree? I should
read up on XS_RESTRICT.

> 
> >>
> >> 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).

What if the XenBus Mirage is the first domain? You could have
have it part of the .init section in Xen and it would be started as
the first domain.

Depending on the value of domid I think is incorrect.

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

Right but it creates its own XenStore ring. Can it send this xsd_sockmsg
with domid_id of zero? Or are you saying this is irrelevant becasue
what you are interested is for the Linux kernel to filter certain
xsd_sockmsg so it won't do something silly?

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

OK, so this all sounds like the OS needs to mediate access? Sorry for
being so dense this morning.

This would imply that the kernel driver would need to understand
the format and disallow the XS_RESTRICT under certain conditions?

That seems reasonable.
> 
> 
> Juergen

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