Re: [Xen-devel] Xenstore domains and XS_RESTRICT

[Juergen Gross <jgross@xxxxxxxx>]

On 08/12/16 08:55, Juergen Gross wrote:
> On 07/12/16 18:10, Ian Jackson wrote:
>> Juergen Gross writes ("Xenstore domains and 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 */
>>
>> I don't think this is a particularly nice extension.  (Also the way
>> you have written it has an endianness hazard.)  What if we decide, at
>> some future point, to support domids >2^16 ?  That's hard right now
>> but I don't want to make it harder.
> 
> Do we support any big endian systems? I don't think so. An endianess
> problem could occur only if there are any big endian systems using the
> old (current) struct xsd_sockmsg.
> 
> Regarding size of domid: this is true.
> 
>>
>> I suggest the following protocol extension instead:
>>
>> Add to xenstore.txt (the list of xenstore commands):
>>
>>   RESTRICTCMD        <domid|><realcommand|><realpayload|>
>>
>>      Here <domid|> is a domain id, and <realcommand|> is a command
>>         number; both of these are 32-bit integers in host byte order.
> 
> Hmm, normally parameters outside the command header are transferred
> using ASCII representation. Do we really want to introduce the first
> exception?
> 
>>
>>      This is an instruction to execute the command <realcommand|>
>>         with payload <realpayload|>.  However, all permissions
>>         checking should be done as if the command had been issued by
>>         domain <domid|>.
>>
>>         The req_id and tx_id, and (if the command affects watches) any
>>         watches that are manipulated, are those of the calling
>>         connection.  So the reply is sent to the xenstore client
>>         (usually, ring client) which sent the RESTRICTCMD command.
>>
>>         If RESTRICTCMD is used to invoke WATCH, the <domid|> from the
>>         RESTRICTCMD is attached to the watch, in xenstored.  Insofar
>>         as watch events are filtered by the permission system, the
>>         <domid|> from the RESTRICTCMD is used for watch events
>>         originating from such a watch.  But the actual watch events
>>         are sent to the connection that called RESTRICTCMD.
>>
>>      This is similar in semantics to RESTRICT but applies to this
>>      one particular command (and its effects), only.
>>
>>         RESTRICTCMD has no effect on, and is not visible through, the
>>         xenstore ring connection of domain <domid|> (if that domain
>>         has one).
>>
>> What do you think ?
>>
>> There is a command length limit implication but I don't think that's
>> important.
> 
> That was the first problem coming to my mind. OTOH I'm not sure this
> is really a problem as users of RESTRICTCMD should have no need to
> use payloads of 4k.
> 
> In summary I see advantages for both solutions. IMO the needed changes
> for my solution will be a little bit smaller, though.

So we have no resolution which approach should be selected: mine or
Ian's (or any other?).

Any preferences?


Juergen


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