|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |