Re: [PATCH v2 0/4] tools/xenstore: fix issue related to XSA-417

["Jürgen Groß" <jgross@suse.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 3397 bytes --]

On 12.05.26 17:48, Oleksii Kurochko wrote:
> 
> 
> On 4/29/26 2:06 PM, Juergen Gross wrote:
>> There is one corner case of XSA-417 which wasn't handled completely
>> with the patches back then.
>>
>> The XSA-417 fixes tried to solve the problem, that a new domU would
>> inherit access permissions to access Xenstore entries with that domid
>> listed in the access rights. In order not to make it easy for a domU
>> to query existence of a domid, adding permission for a non-existing
>> domain is not rejected by Xenstore. The XSA-417 patches solved that
>> problem by adding a flag to a permission entry referencing a not
>> existing domain, indicating that the permission should not be
>> effective for Xenstore.
>>
>> One corner case was not handled:
>>
>> Consider guest 1 and guest 2 running. Guest 1 adds guest 2 to be able
>> to access a Xenstore entry. Now guest 2 is removed from the system and
>> a new guest 3 with the same domid as guest 2 had is being created.
>>
>> When guest 3 would try now to access the Xenstore entry, it would fail,
>> as Xenstore would see that the Xenstore entry is older than guest 3.
>>
>> But if guest 1 is modifying the permissions of the Xenstore entry
>> again, e.g. by adding another domain, the permission entry for guest 2
>> would lose its "special flag", resulting in guest 3 now really gaining
>> access to the Xenstore entry.
>>
>> This series is fixing this problem by the following means:
>>
>> - In order to allow guests to know that a Xenstore entry permission
>>    might have gone stale, allow unprivileged guests to receive
>>    @releaseDomain watch events. This doesn't open a security hole, as
>>    the only knowledge which can by gathered from that change is that a
>>    domain is gone, not that a domain with a specific domid is existing.
>>
>> - When a domain is removed, remove all permissions relating to this
>>    domain from all Xenstore entries.
>>
>> Note that this issue was discussed by the Xen security team and we
>> decided not to issue an XSA, as there are no known use cases where one
>> unprivileged guest would grant access to its Xenstore nodes to more
>> than one other unprivileged guests.
>>
>> We decided to delay this patch series until the watch depth feature has
>> been committed, as with that feature available it is now possible for
>> a guest to handle the death of a specific domain in a sane way.
>>
>> Changes in V2:
>> - some minor comments addressed
>>
>> Denis Mukhin (1):
>>    xen/public: introduce DOMID_ANY
>>
>> Juergen Gross (3):
>>    tools/xenstored: add support for "all domains" node permission
>>    tools/xenstored: allow @releaseDomain watch for all domains
>>    tools/xenstored: remove permissions related to dead domain
>>
>>   docs/man/xl.cfg.5.pod.in        |  4 ++
>>   tools/xenstored/core.c          | 45 ++++++++++++++-----
>>   tools/xenstored/domain.c        | 78 +++++++++++++++++++++------------
>>   tools/xenstored/domain.h        |  3 +-
>>   xen/include/public/io/xs_wire.h |  2 +
>>   xen/include/public/xen.h        |  7 +++
>>   6 files changed, 100 insertions(+), 39 deletions(-)
>>
> 
> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thank you.

Any rest maintainer willing to ack patch 1?


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]