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

[Jürgen Groß <jgross@xxxxxxxx>]

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@xxxxxxxxx>
Thank you.

Any rest maintainer willing to ack patch 1?


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature