[PATCH XEN v8 28/29] tools/libs/*: Introduce APIs to restrict handles to a specific domain.

From: Ian Campbell <ian.campbell@citrix.com>
To: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, xen-devel@lists.xen.org
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [PATCH XEN v8 28/29] tools/libs/*: Introduce APIs to restrict handles to a specific domain.
Date: Fri, 15 Jan 2016 13:23:07 +0000	[thread overview]
Message-ID: <1452864188-2417-29-git-send-email-ian.campbell@citrix.com> (raw)
In-Reply-To: <1452864188-2417-1-git-send-email-ian.campbell@citrix.com>

These are intended to allow user space processes (in particular QEMU)
to lock down all the handles at start of day and then drop the
privileges which would allow them to open any new unrestricted handles
(e.g. setuid or similar). This will reduce the privileges which taking
over such a process would gain an attacker wrt other domains in the
system.

These are currently unimplemented on all platforms, however the API
semantics are defined as the basis for discussion, and so that
consumers can rely on this interface always having been present rather
than requiring compile time API checks.

It is expected that these will be implemented by adding new ioctl
calls on the underlying driver and that the restrictions will be
enforced at the kernel interface layer (most likely by the kernel
itself).

For evtchn, foreignmemory, gnttab and gntshr this is hopefully
reasonably straightforward.

For call it is not so clear cut. Clearly the kernel cannot enforce
these restrictions for hypercalls which are not stable (domctl et al)
so they can never be on the whitelist. It may also be that potential
users would like to restrict the handle further than just a given
target domain, i.e. to a specific set of functionality (e.g. "things a
device model might reasonably do"). I think we will also need some way
to discover whether a given set of interfaces is available to a
restricted handle, in order to support the addition of new
functionality.

Notes:

- On many (all?) platforms libxencall and libxenforeignmemory are
  implemented by the same underlying privcmd driver. The platform
  level ioctl interface should support restricting the handle to only
  one or the other.
- On platforms with multiple privilege mapping ioctl variants should
  consider only allowing the newest/currently preferred one on a
  restricted handle. e.g. on Linux this would allow
  IOCTL_PRIVCMD_MMAPBATCH_V2 but not IOCTL_PRIVCMD_MMAPBATCH. (Of
  course any subsequently introduced _V3 would be subject to
  compatibility concerns)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v8: New

This applies on top of the Xen portion of "Begin to disentangle
libxenctrl and provide some stable libraries", v7, plus a couple of
minor fixes which will be in v8. All of this can be found in the
"vwip" branch of the tree referenced by that series at
git://xenbits.xen.org/people/ianc/libxenctrl-split/xen.git.
---
 tools/libs/call/core.c                             |  7 +++
 tools/libs/call/include/xencall.h                  | 34 ++++++++++++++
 tools/libs/call/libxencall.map                     |  2 +
 tools/libs/evtchn/core.c                           |  7 +++
 tools/libs/evtchn/include/xenevtchn.h              | 36 +++++++++++++++
 tools/libs/evtchn/libxenevtchn.map                 |  2 +
 tools/libs/foreignmemory/core.c                    |  7 +++
 .../libs/foreignmemory/include/xenforeignmemory.h  | 22 +++++++++
 tools/libs/foreignmemory/libxenforeignmemory.map   |  3 ++
 tools/libs/gnttab/gntshr_core.c                    |  8 ++++
 tools/libs/gnttab/gnttab_core.c                    |  7 +++
 tools/libs/gnttab/include/xengnttab.h              | 52 ++++++++++++++++++++++
 tools/libs/gnttab/libxengnttab.map                 |  8 +++-
 13 files changed, 193 insertions(+), 2 deletions(-)

diff --git a/tools/libs/call/core.c b/tools/libs/call/core.c
index bbf88de..07283da 100644
--- a/tools/libs/call/core.c
+++ b/tools/libs/call/core.c
@@ -14,6 +14,7 @@
  */
 
 #include <stdlib.h>
+#include <errno.h>
 
 #include "private.h"
 
@@ -70,6 +71,12 @@ int xencall_close(xencall_handle *xcall)
     return rc;
 }
 
+int xencall_restrict_target(xencall_handle *xcall, uint32_t domid)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
 int xencall0(xencall_handle *xcall, unsigned int op)
 {
     privcmd_hypercall_t call = {
diff --git a/tools/libs/call/include/xencall.h b/tools/libs/call/include/xencall.h
index 559624a..47c394d 100644
--- a/tools/libs/call/include/xencall.h
+++ b/tools/libs/call/include/xencall.h
@@ -73,6 +73,40 @@ xencall_handle *xencall_open(xentoollog_logger *logger, unsigned open_flags);
 int xencall_close(xencall_handle *xcall);
 
 /*
+ * Attempt to restrict the given xcall handle to only be able to
+ * target the given domain.
+ *
+ * On success returns 0, after which only hypercalls which are on a
+ * platform specific whitelist can be called and the arguments will be
+ * audited by the platform to ensure that the target domain is
+ * domid.
+ *
+ * Subsequent attempts to call any hypercall not on the platform
+ * specific whitelist will return -1 setting errno to ENOSYS.
+ *
+ * Subsequent attempts to call any hypercall on the platform specific
+ * whitelist with any other target domain return -1 setting errno to
+ * EPERM.
+ *
+ * These restrictions will be implemented by the platform in a way
+ * which cannot be circumvented by a userspace process. Further
+ * privilege drops (such as using setuid(2) etc) may also be required
+ * to prevent a compromised process from simply opening a second
+ * handle
+ *
+ * XXX which hypercalls are restricted, per platform list, do we need
+ * a way to probe? Do we want to be able to restrict to particular
+ * subsets of whitelisted hypercalls?
+ *
+ * On failure returns -1 and sets errno:
+ *   ENOSYS: The platform is not able to support restricting the
+ *           target domain.
+ *   Other: The platform should be able to support restricting the
+ *          target domain, but was unable to do so.
+ */
+int xencall_restrict_target(xencall_handle *xcall, uint32_t domid);
+
+/*
  * Call hypercalls with varying numbers of arguments.
  *
  * On success the return value of the hypercall is the return value of
diff --git a/tools/libs/call/libxencall.map b/tools/libs/call/libxencall.map
index 2f96144..d39f88e 100644
--- a/tools/libs/call/libxencall.map
+++ b/tools/libs/call/libxencall.map
@@ -3,6 +3,8 @@ VERS_1.0 {
 		xencall_open;
 		xencall_close;
 
+		xencall_restrict_target;
+
 		xencall0;
 		xencall1;
 		xencall2;
diff --git a/tools/libs/evtchn/core.c b/tools/libs/evtchn/core.c
index c31e08c..5f68f52 100644
--- a/tools/libs/evtchn/core.c
+++ b/tools/libs/evtchn/core.c
@@ -15,6 +15,7 @@
 
 #include <unistd.h>
 #include <stdlib.h>
+#include <errno.h>
 
 #include "private.h"
 
@@ -61,6 +62,12 @@ int xenevtchn_close(xenevtchn_handle *xce)
     return rc;
 }
 
+int xenevtchn_restrict_target(xenevtchn_handle *xce, uint32_t domid)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/evtchn/include/xenevtchn.h b/tools/libs/evtchn/include/xenevtchn.h
index 4d26161..d67a4e4 100644
--- a/tools/libs/evtchn/include/xenevtchn.h
+++ b/tools/libs/evtchn/include/xenevtchn.h
@@ -74,6 +74,42 @@ xenevtchn_handle *xenevtchn_open(xentoollog_logger *logger, unsigned open_flags)
 int xenevtchn_close(xenevtchn_handle *xce);
 
 /*
+ * Attempt to restrict the given evtchn handle to only operate on the
+ * given domain.
+ *
+ * On success returns 0, after which:
+ *
+ * - Any operations which take a peer domain as an argument can only
+ *   be called with the specified target domain. Subsequent attempts
+ *   to call any such interface with another domain will return -1
+ *   setting errno to EPERM.
+ *
+ * - Any operations which take an evtchn_port_t are not restricted
+ *   other than by the requirement to have previously bound that
+ *   evtchn to the handle. Therefore users of the restrict interface
+ *   should take care not to bind any event channels relating to other
+ *   domains prior to enforcing the restriction. The restrictions on
+ *   xenevtchn_bind_*() (which take a domain id, see previous point)
+ *   suffice to prevent any new such bindings being created.
+ *
+ * - xenevtchn_bind_virq is not permitted and will return -1 setting
+ *   errno to EPERM.
+ *
+ * These restrictions will be implemented by the platform in a way
+ * which cannot be circumvented by a userspace process. Further
+ * privilege drops (such as using setuid(2) etc) may also be required
+ * to prevent a compromised process from simply opening a second
+ * handle
+ *
+ * On failure returns -1 and sets errno:
+ *   ENOSYS: The platform is not able to support restricting the
+ *           target domain.
+ *   Other: The platform should be able to support restricting the
+ *          target domain, but was unable to do so.
+ */
+int xenevtchn_restrict_target(xenevtchn_handle *xce, uint32_t domid);
+
+/*
  * Return an fd that can be select()ed on.
  *
  * Note that due to bugs, setting this fd to non blocking may not
diff --git a/tools/libs/evtchn/libxenevtchn.map b/tools/libs/evtchn/libxenevtchn.map
index 625a1e2..08e9dd5 100644
--- a/tools/libs/evtchn/libxenevtchn.map
+++ b/tools/libs/evtchn/libxenevtchn.map
@@ -3,6 +3,8 @@ VERS_1.0 {
 		xenevtchn_open;
 		xenevtchn_close;
 
+		xenevtchn_restrict_target;
+
 		xenevtchn_fd;
 
 		xenevtchn_bind_unbound_port;
diff --git a/tools/libs/foreignmemory/core.c b/tools/libs/foreignmemory/core.c
index cfb0a73..73e8034 100644
--- a/tools/libs/foreignmemory/core.c
+++ b/tools/libs/foreignmemory/core.c
@@ -62,6 +62,13 @@ int xenforeignmemory_close(xenforeignmemory_handle *fmem)
     return rc;
 }
 
+int xenforeignmemory_restrict_target(xenforeignmemory_handle *fmem,
+                                     uint32_t domid)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
 void *xenforeignmemory_map(xenforeignmemory_handle *fmem,
                            uint32_t dom, int prot,
                            size_t num,
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h b/tools/libs/foreignmemory/include/xenforeignmemory.h
index 3724c63..350ca75 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -74,6 +74,28 @@ xenforeignmemory_handle *xenforeignmemory_open(xentoollog_logger *logger,
 int xenforeignmemory_close(xenforeignmemory_handle *fmem);
 
 /*
+ * Attempt to restrict the given handle to only target the given
+ * domain.
+ *
+ * On success returns 0, after which calls to xenforeignmemory_map
+ * which pass a domain other than the given domain will return -1
+ * setting errno to EPERM.
+ *
+ * This restriction will be implemented by the platform in a way which
+ * cannot be circumvented by a userspace process. Further privilege
+ * drops (such as using setuid(2) etc) may also be required to prevent
+ * a compromised process from simply opening a second handle
+ *
+ * On failure returns -1 and sets errno:
+ *   ENOSYS: The platform is not able to support restricting the
+ *           target domain.
+ *   Other: The platform should be able to support restricting the
+ *          target domain, but was unable to do so.
+ */
+int xenforeignmemory_restrict_target(xenforeignmemory_handle *fmem,
+                                     uint32_t domid);
+
+/*
  * Maps a range within one domain to a local address range.  Mappings
  * must be unmapped with xenforeignmemory_unmap and should follow the
  * same rules as mmap regarding page alignment.
diff --git a/tools/libs/foreignmemory/libxenforeignmemory.map b/tools/libs/foreignmemory/libxenforeignmemory.map
index df206b3..dc1e0a1 100644
--- a/tools/libs/foreignmemory/libxenforeignmemory.map
+++ b/tools/libs/foreignmemory/libxenforeignmemory.map
@@ -2,6 +2,9 @@ VERS_1.0 {
 	global:
 		xenforeignmemory_open;
 		xenforeignmemory_close;
+
+		xenforeignmemory_restrict_target;
+
 		xenforeignmemory_map;
 		xenforeignmemory_unmap;
 	local: *; /* Do not expose anything by default */
diff --git a/tools/libs/gnttab/gntshr_core.c b/tools/libs/gnttab/gntshr_core.c
index 7f6bf9d..0347a16 100644
--- a/tools/libs/gnttab/gntshr_core.c
+++ b/tools/libs/gnttab/gntshr_core.c
@@ -19,6 +19,7 @@
  */
 
 #include <stdlib.h>
+#include <errno.h>
 
 #include "private.h"
 
@@ -64,6 +65,13 @@ int xengntshr_close(xengntshr_handle *xgs)
     free(xgs);
     return rc;
 }
+
+int xengntshr_restrict_target(xengntshr_handle *xgs, uint32_t domid)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
 void *xengntshr_share_pages(xengntshr_handle *xcg, uint32_t domid,
                             int count, uint32_t *refs, int writable)
 {
diff --git a/tools/libs/gnttab/gnttab_core.c b/tools/libs/gnttab/gnttab_core.c
index 5d0474d..77ce1670 100644
--- a/tools/libs/gnttab/gnttab_core.c
+++ b/tools/libs/gnttab/gnttab_core.c
@@ -19,6 +19,7 @@
  */
 
 #include <stdlib.h>
+#include <errno.h>
 
 #include "private.h"
 
@@ -65,6 +66,12 @@ int xengnttab_close(xengnttab_handle *xgt)
     return rc;
 }
 
+int xengnttab_restrict_target(xengnttab_handle *xgt, uint32_t domid)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
 int xengnttab_set_max_grants(xengnttab_handle *xgt, uint32_t count)
 {
     return osdep_gnttab_set_max_grants(xgt, count);
diff --git a/tools/libs/gnttab/include/xengnttab.h b/tools/libs/gnttab/include/xengnttab.h
index 7bf8462..8d0d26c 100644
--- a/tools/libs/gnttab/include/xengnttab.h
+++ b/tools/libs/gnttab/include/xengnttab.h
@@ -148,6 +148,33 @@ xengnttab_handle *xengnttab_open(xentoollog_logger *logger, unsigned open_flags)
  */
 int xengnttab_close(xengnttab_handle *xgt);
 
+/*
+ * Attempt to restrict the given handle to only target the given
+ * domain.
+ *
+ * On success returns 0, after which:
+ *
+ * - Calls to xengnttab_map_*() which are passed a domain other than
+ *   the given domain (either as an argument or as any member of a
+ *   domid array argument, regardless of the validity of other members
+ *   of the array) will return -1 setting errno to EPERM.
+ *
+ * - Calls to xengnttab_set_max_grants() will return -1 having set
+ *   errno to EPERM.
+ *
+ * This restriction will be implemented by the platform in a way which
+ * cannot be circumvented by a userspace process. Further privilege
+ * drops (such as using setuid(2) etc) may also be required to prevent
+ * a compromised process from simply opening a second handle
+ *
+ * On failure returns -1 and sets errno:
+ *   ENOSYS: The platform is not able to support restricting the
+ *           target domain.
+ *   Other: The platform should be able to support restricting the
+ *          target domain, but was unable to do so.
+ */
+int xengnttab_restrict_target(xengnttab_handle *xgt, uint32_t domid);
+
 /**
  * Memory maps a grant reference from one domain to a local address range.
  * Mappings should be unmapped with xengnttab_unmap.  Logs errors.
@@ -305,6 +332,31 @@ xengntshr_handle *xengntshr_open(xentoollog_logger *logger,
  */
 int xengntshr_close(xengntshr_handle *xgs);
 
+/*
+ * Attempt to restrict the given handle to only target the given
+ * domain.
+ *
+ * On success returns 0, after which:
+ *
+ * - Calls to xengntshr_share_*() which are passed a domain other than
+ *   the given domain will return -1 setting errno to EPERM.
+ *
+ * - Calls to xengnttab_set_max_grants() will return -1 having set
+ *   errno to EPERM.
+ *
+ * This restriction will be implemented by the platform in a way which
+ * cannot be circumvented by a userspace process. Further privilege
+ * drops (such as using setuid(2) etc) may also be required to prevent
+ * a compromised process from simply opening a second handle
+ *
+ * On failure returns -1 and sets errno:
+ *   ENOSYS: The platform is not able to support restricting the
+ *           target domain.
+ *   Other: The platform should be able to support restricting the
+ *          target domain, but was unable to do so.
+ */
+int xengntshr_restrict_target(xengntshr_handle *xgs, uint32_t domid);
+
 /**
  * Allocates and shares pages with another domain.
  *
diff --git a/tools/libs/gnttab/libxengnttab.map b/tools/libs/gnttab/libxengnttab.map
index 66e8c12..c3d7d49 100644
--- a/tools/libs/gnttab/libxengnttab.map
+++ b/tools/libs/gnttab/libxengnttab.map
@@ -3,6 +3,8 @@ VERS_1.0 {
 		xengnttab_open;
 		xengnttab_close;
 
+		xengnttab_restrict_target;
+
 		xengnttab_set_max_grants;
 
 		xengnttab_map_domain_grant_refs;
@@ -11,10 +13,12 @@ VERS_1.0 {
 		xengnttab_map_grant_refs;
 
 		xengnttab_unmap;
-		
+
 		xengntshr_open;
 		xengntshr_close;
-		
+
+		xengntshr_restrict_target;
+
 		xengntshr_share_page_notify;
 		xengntshr_share_pages;
 		
-- 
2.1.4
