The current code was incorrectly using SECCLASS_XEN instead of
SECCLASS_XEN2, resulting in the wrong permission being checked.
GET_CPU_LEVELLING_CAPS was checking MTRR_DEL
GET_CPU_FEATURESET was checking MTRR_READ
The default XSM policy only allowed these permissions to dom0, so this
didn't result in a security issue there.
Signed-off-by: Daniel De Graaf <dgde...@tycho.nsa.gov>
---
xen/xsm/flask/hooks.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 819e25d3af..57be18d6d4 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -814,10 +814,12 @@ static int flask_sysctl(int cmd)
return domain_has_xen(current->domain, XEN__TMEM_CONTROL);
case XEN_SYSCTL_get_cpu_levelling_caps:
- return domain_has_xen(current->domain, XEN2__GET_CPU_LEVELLING_CAPS);
+ return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
+ XEN2__GET_CPU_LEVELLING_CAPS);
case XEN_SYSCTL_get_cpu_featureset:
- return domain_has_xen(current->domain, XEN2__GET_CPU_FEATURESET);
+ return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
+ XEN2__GET_CPU_FEATURESET);
case XEN_SYSCTL_livepatch_op:
return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
--
2.13.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
