]> xenbits.xensource.com Git - people/liuw/mini-os.git/commitdiff
libxl: Restrict permissions on PV console device xenstore nodes xen-4.3.0-rc6 xen-4.3.1-rc1 xen-4.3.1-rc2 xen-4.3.2-rc1 xen-4.3.3-rc1 xen-4.3.3-rc2 xen-RELEASE-4.3.0 xen-RELEASE-4.3.1 xen-RELEASE-4.3.2 xen-RELEASE-4.3.3
authorIan Jackson <ian.jackson@eu.citrix.com>
Tue, 25 Jun 2013 10:24:22 +0000 (11:24 +0100)
committerIan Jackson <Ian.Jackson@eu.citrix.com>
Tue, 25 Jun 2013 10:24:22 +0000 (11:24 +0100)
Matthew Daley has observed that the PV console protocol places sensitive host
state into a guest writeable xenstore locations, this includes:

 - The pty used to communicate between the console backend daemon and its
   client, allowing the guest administrator to read and write arbitrary host
   files.
 - The output file, allowing the guest administrator to write arbitrary host
   files or to target arbitrary qemu chardevs which include sockets, udp, ptr,
   pipes etc (see -chardev in qemu(1) for a more complete list).
 - The maximum buffer size, allowing the guest administrator to consume more
   resources than the host administrator has configured.
 - The backend to use (qemu vs xenconsoled), potentially allowing the guest
   administrator to confuse host software.

So we arrange to make the sensitive keys in the xenstore frontend directory
read only for the guest. This is safe since the xenstore permissions model,
unlike POSIX directory permissions, does not allow the guest to remove and
recreate a node if it has write access to the containing directory.

There are a few associated wrinkles:

 - The primary PV console is "special". It's xenstore node is not under the
   usual /devices/ subtree and it does not use the customary xenstore state
   machine protocol. Unfortunately its directory is used for other things,
   including the vnc-port node, which we do not want the guest to be able to
   write to. Rather than trying to track down all the possible secondary uses
   of this directory just make it r/o to the guest. All newly created
   subdirectories inherit these permissions and so are now safe by default.

 - The other serial consoles do use the customary xenstore state machine and
   therefore need write access to at least the "protocol" and "state" nodes,
   however they may also want to use arbitrary "feature-foo" nodes (although
   I'm not aware of any) and therefore we cannot simply lock down the entire
   frontend directory. Instead we add support to libxl__device_generic_add for
   frontend keys which are explicitly read only and use that to lock down the
   sensitive keys.

 - Minios' console frontend wants to write the "type" node, which it has no
   business doing since this is a host/toolstack level decision. This fails
   now that the node has become read only to the PV guest. Since the toolstack
   already writes this node just remove the attempt to set it.

This is a security issue, XSA-57.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
console/xenbus.c

index 77de82a0fa313c7123af51298537385bfb8be08c..e65baf75a970f54fa09378b2fc3b00f507ff905a 100644 (file)
@@ -122,12 +122,6 @@ again:
         goto abort_transaction;
     }
 
-    err = xenbus_printf(xbt, nodename, "type", "%s", "ioemu");
-    if (err) {
-        message = "writing type";
-        goto abort_transaction;
-    }
-
     snprintf(path, sizeof(path), "%s/state", nodename);
     err = xenbus_switch_state(xbt, path, XenbusStateConnected);
     if (err) {