Re: [Xen-devel] Xenstore domains and XS_RESTRICT

[Juergen Gross <jgross@xxxxxxxx>]

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

That would help, yes. :-)

With XS_RESTRICT a privileged connection can drop its privileges to
those of a specific domain. This is meant to be used e.g. by qemu
together with dropping root privileges after initialization to avoid
causing damage to odom0/other domains due to security leaks.

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

It is correct. The comparison done is to either 0 or privileged domain
(set via start parameter of xenstore domain/daemon).

> 
>>
>>>> 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 domid has to be correct for being able to get a grant for its ring.
So it isn't transferred via the ring of the new domain, but from dom0
via the XS_INTRODUCE wire command (which is allowed for the privileged
domain only).

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

Yes. As it does today for start/end of transactions and for setting
watches.

> That seems reasonable.

I hope so. :-)


Juergen

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