[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

Juergen Gross (4):
  xen/public: introduce DOMID_ANY
  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        | 77 +++++++++++++++++++++------------
 tools/xenstored/domain.h        |  3 +-
 xen/include/public/io/xs_wire.h |  2 +
 xen/include/public/xen.h        |  7 +++
 6 files changed, 99 insertions(+), 39 deletions(-)

-- 
2.53.0




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.