Skip to contentSkip to conversation

Assign a default SSID to guests

PATCH In review Ian Campbell 3 participants 16 messages May 20, 2015 – May 21, 2015

lore
Share & tools
lore
#0 lore raw

v3 cover Assign a default SSID to guests

Compared with v3 this uses Daniel's more comprehensive policy patch and adds a default ssidref for stubdoms too.

Tested with and without XSM enabled for normal guests and HVM guests with qemu in dom0. Stubdoms appeared to be broken in the base case, so I haven't tested that really.

Ian.

#1 lore raw

PATCH v3 1/6 tools: Add AWK to set of tools checked for by configure

We are going to need this to generate the userspace flask.h header.

Please rerun autogen.sh when committing.

---
 config/Tools.mk.in |    1 +
 tools/configure.ac |    2 ++
 2 files changed, 3 insertions(+)
config/Tools.mk.in +1 -0
index e7da99d..d67352e 100644
@@ -23,6 +23,7 @@ AS86                := @AS86@
 LD86                := @LD86@
 BCC                 := @BCC@
 IASL                := @IASL@
+AWK                 := @AWK@
 FETCHER             := @FETCHER@
 SEABIOS_PATH        := @seabios_path@
 OVMF_PATH           := @ovmf_path@
tools/configure.ac +2 -0
index d31c2f3..c975dfc 100644
@@ -247,6 +247,7 @@ AC_ARG_VAR([AS86], [Path to as86 tool])
 AC_ARG_VAR([LD86], [Path to ld86 tool])
 AC_ARG_VAR([BCC], [Path to bcc tool])
 AC_ARG_VAR([IASL], [Path to iasl tool])
+AC_ARG_VAR([AWK], [Path to awk tool])
 
 # Checks for programs.
 AC_PROG_CC
@@ -255,6 +256,7 @@ AC_PROG_INSTALL
 AC_PATH_PROG([BISON], [bison])
 AC_PATH_PROG([FLEX], [flex])
 AX_PATH_PROG_OR_FAIL([PERL], [perl])
+AX_PATH_PROG_OR_FAIL([AWK], [awk])
 
 AC_PROG_OCAML
 AC_PROG_FINDLIB
Signature · 1 line
1.7.10.4
#2 lore raw

PATCH v3 2/6 xen: flask: Pass output directory as a parameter to mkflask.sh

In reply to Ian Campbell

When called from the tools side in a later patch we will want to direct its output to the appropriate place.

---
 xen/xsm/flask/Makefile          |    2 +-
 xen/xsm/flask/policy/mkflask.sh |    9 ++++++---
 2 files changed, 7 insertions(+), 4 deletions(-)
xen/xsm/flask/Makefile +1 -1
index 1256512..12fc3a9 100644
@@ -22,7 +22,7 @@ ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
 $(obj-y) ss/built_in.o: $(ALL_H_FILES)
 
 $(FLASK_H_FILES): $(FLASK_H_DEPEND)
-	$(CONFIG_SHELL) policy/mkflask.sh $(AWK) $(FLASK_H_DEPEND)
+	$(CONFIG_SHELL) policy/mkflask.sh $(AWK) include $(FLASK_H_DEPEND)
 
 $(AV_H_FILES): $(AV_H_DEPEND)
 	$(CONFIG_SHELL) policy/mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
xen/xsm/flask/policy/mkflask.sh +6 -3
index e8d8fb5..9e24020 100644
@@ -8,10 +8,13 @@ set -e
 awk=$1
 shift 1
 
+output_dir=$1
+shift 1
+
 # output file
-output_file="include/flask.h"
-debug_file="include/class_to_string.h"
-debug_file2="include/initial_sid_to_string.h"
+output_file="$output_dir/flask.h"
+debug_file="$output_dir/class_to_string.h"
+debug_file2="$output_dir/initial_sid_to_string.h"
 
 cat $* | $awk "
 BEGIN	{
Signature · 1 line
1.7.10.4
#4 lore raw

PATCH v3 3/6 xen: flask: Restrict generated header to xen + tools

In reply to Ian Campbell

This isn't strictly necessary but since it is going to be exposed via tools/include in a later patch this will help prevent accidental leakage beyond the tools.

---
 xen/xsm/flask/policy/mkflask.sh |    2 ++
 1 file changed, 2 insertions(+)
xen/xsm/flask/policy/mkflask.sh +2 -0
index 9e24020..989a323 100644
@@ -28,6 +28,7 @@ BEGIN	{
 
 		printf("#ifndef _SELINUX_FLASK_H_\n") > outfile;
 		printf("#define _SELINUX_FLASK_H_\n") > outfile;
+		printf("\n#if defined(__XEN__) || defined(__XEN_TOOLS__)\n") > outfile;
 		printf("\n/*\n * Security object class definitions\n */\n") > outfile;
 		printf("/* This file is automatically generated.  Do not edit. */\n") > debugfile;
 		printf("/*\n * Security object class definitions\n */\n") > debugfile;
@@ -91,6 +92,7 @@ END	{
 		for (i = 0; i < 34; i++) 
 			printf(" ") > outfile; 
 		printf("%d\n", sid_value) > outfile; 
+		printf("\n#endif /* __XEN__ || __XEN_TOOLS__ */\n") > outfile;
 		printf("\n#endif\n") > outfile;
 		printf("};\n\n") > debugfile2;
 	}'
Signature · 1 line
1.7.10.4
#6 lore raw

PATCH v3 4/6 tools: Expose XSM Flask initial SIDs list to tools

In reply to Ian Campbell

By generating tools/include/xen-xsm/flask/flask.h using the same tool as used during the hypervisor build.

Note that this is done regardless of whether XSM is enabled, since we want the tools to be agnostic to whether or not XSM is enabled in the hypervisor

---
 .gitignore             |    1 +
 tools/include/Makefile |   16 ++++++++++++++--
 2 files changed, 15 insertions(+), 2 deletions(-)
.gitignore +1 -0
index c6185a0..3bc9cd9 100644
@@ -147,6 +147,7 @@ tools/hotplug/Linux/xen-hotplug-common.sh
 tools/hotplug/Linux/xendomains
 tools/hotplug/NetBSD/rc.d/xencommons
 tools/include/xen/*
+tools/include/xen-xsm/*
 tools/include/xen-foreign/*.(c|h|size)
 tools/include/xen-foreign/checker
 tools/libxl/libxlu_cfg_y.output
tools/include/Makefile +14 -2
index 601f79c..869b3f3 100644
@@ -1,8 +1,11 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+# Relative to $(XEN_ROOT)/xen/xsm/flask
+FLASK_H_DEPEND := policy/initial_sids
+
 .PHONY: all
-all: xen-foreign xen/.dir
+all: xen-foreign xen/.dir xen-xsm/.dir
 
 .PHONY: xen-foreign
 xen-foreign:
@@ -19,6 +22,15 @@ xen/.dir:
 	ln -s ../xen-foreign xen/foreign
 	touch $@
 
+# Not xen/xsm as that clashes with link to
+# $(XEN_ROOT)/xen/include/public/xsm above.
+xen-xsm/.dir: $(XEN_ROOT)/xen/xsm/flask/policy/mkflask.sh \
+	      $(patsubst %,$(XEN_ROOT)/xen/xsm/flask/%,$(FLASK_H_DEPEND))
+	mkdir -p xen-xsm/flask
+	cd $(XEN_ROOT)/xen/xsm/flask/ && \
+		$(SHELL) policy/mkflask.sh $(AWK) $(CURDIR)/xen-xsm/flask $(FLASK_H_DEPEND)
+	touch $@
+
 .PHONY: install
 install: all
 	$(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)/xen/arch-x86
@@ -47,7 +59,7 @@ install: all
 
 .PHONY: clean
 clean:
-	rm -rf xen
+	rm -rf xen xen-xsm
 	$(MAKE) -C xen-foreign clean
 
 
Signature · 1 line
1.7.10.4
Acked-by on v3 4/6
#7 lore raw

Re: [PATCH v3 4/6] tools: Expose XSM Flask initial SIDs list to tools

Quoted 9 lines · Ian Campbell

By generating tools/include/xen-xsm/flask/flask.h using the same tool as used during the hypervisor build.

Note that this is done regardless of whether XSM is enabled, since we want the tools to be agnostic to whether or not XSM is enabled in the hypervisor

#8 lore raw

PATCH v3 5/6 flask/policy: add initial SIDs for domU/domDM

In reply to Ian Campbell

From: Daniel De Graaf <[email protected]>

Add default security contexts to the XSM policy for use by the toolstack when a domain is created without specifying an explicit security label.

---
v3: New more comprehensive patch from Daniel

---
 docs/misc/xsm-flask.txt                      |    6 +++---
 tools/flask/policy/policy/initial_sids       |    4 ++++
 tools/flask/policy/policy/modules/xen/xen.te |   11 +++--------
 xen/xsm/flask/policy/initial_sids            |    2 ++
 4 files changed, 12 insertions(+), 11 deletions(-)
docs/misc/xsm-flask.txt +3 -3
index d63a8a7..7249f40 100644
@@ -213,9 +213,9 @@ that can be used without dom0 disaggregation. The main types for domUs are:
  - nomigrate_t is a domain that must be created via the nomigrate_t_building
    type, and whose memory cannot be read by dom0 once created
 
-HVM domains with stubdomain device models use two types (one per domain):
- - domHVM_t is an HVM domain that uses a stubdomain device model
- - dm_dom_t is the device model for a domain with type domHVM_t
+HVM domains with stubdomain device models also need a type for the stub domain.
+The example policy defines dm_dom_t for the device model of a domU_t domain;
+there are no device model types defined for the other domU types.
 
 One disadvantage of using type enforcement to enforce isolation is that a new
 type is needed for each group of domains. The user field can be used to address
tools/flask/policy/policy/initial_sids +4 -0
index 5de0bbf..6b7b7ef 100644
@@ -12,3 +12,7 @@ sid irq gen_context(system_u:object_r:irq_t,s0)
 sid iomem gen_context(system_u:object_r:iomem_t,s0)
 sid ioport gen_context(system_u:object_r:ioport_t,s0)
 sid device gen_context(system_u:object_r:device_t,s0)
+
+# Initial SIDs used by the toolstack for domains without defined labels
+sid domU gen_context(system_u:system_r:domU_t,s0)
+sid domDM gen_context(system_u:system_r:dm_dom_t,s0)
tools/flask/policy/policy/modules/xen/xen.te +3 -8
index e555d11..ce70639 100644
@@ -151,18 +151,13 @@ domain_comms(domU_t, prot_domU_t)
 domain_comms(prot_domU_t, prot_domU_t)
 domain_self_comms(prot_domU_t)
 
-# domHVM_t is meant to be paired with a qemu-dm stub domain of type dm_dom_t
-declare_domain(domHVM_t)
-create_domain(dom0_t, domHVM_t)
-manage_domain(dom0_t, domHVM_t)
-domain_comms(dom0_t, domHVM_t)
-domain_self_comms(domHVM_t)
-
+# Device model for domU_t.  You can define distinct types for device models for
+# domains of other types, or add more make_device_model lines for this type.
 declare_domain(dm_dom_t)
 create_domain(dom0_t, dm_dom_t)
 manage_domain(dom0_t, dm_dom_t)
 domain_comms(dom0_t, dm_dom_t)
-make_device_model(dom0_t, dm_dom_t, domHVM_t)
+make_device_model(dom0_t, dm_dom_t, domU_t)
 
 # nomigrate_t must be built via the nomigrate_t_building label; once built,
 # dom0 cannot read its memory.
xen/xsm/flask/policy/initial_sids +2 -0
index e508bde..7eca70d 100644
@@ -13,4 +13,6 @@ sid ioport
 sid iomem
 sid irq
 sid device
+sid domU
+sid domDM
 # FLASK
Signature · 1 line
1.7.10.4
#9 lore raw

PATCH v3 6/6 libxl: assign a default ssidref (XSM label) to guests

In reply to Ian Campbell

We have now arranged for SECINITSID_DOMU and SECINITSID_DOMDM to be defined (correspondng to system_u:system_r:domU_t and system_u:system_r:dm_dom_t respectively in the default policy). Use these as the default for the SSID of every (stub)domain.

---
v2: Set ssidref rather than label. It is no longer necessary to
reorder things in libxl.c.
v3: Set device_model_ssidref too if stubdoms are enabled.
I didn't apply Wei's ack due to this change.

---
 tools/libxl/libxl_create.c |    9 +++++++++
 1 file changed, 9 insertions(+)
tools/libxl/libxl_create.c +9 -0
index f0da7dc..853c252 100644
@@ -25,6 +25,8 @@
 #include <xen/hvm/hvm_info_table.h>
 #include <xen/hvm/e820.h>
 
+#include <xen-xsm/flask/flask.h>
+
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                          libxl_domain_create_info *c_info)
 {
@@ -42,6 +44,9 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
     libxl_defbool_setdefault(&c_info->run_hotplug_scripts, true);
     libxl_defbool_setdefault(&c_info->driver_domain, false);
 
+    if (!c_info->ssidref)
+        c_info->ssidref = SECINITSID_DOMU;
+
     return 0;
 }
 
@@ -111,6 +116,10 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
 
     libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
 
+    if (libxl_defbool_val(b_info->device_model_stubdomain) &&
+        !b_info->device_model_ssidref)
+        b_info->device_model_ssidref = SECINITSID_DOMDM;
+
     if (!b_info->device_model_version) {
         if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
             if (libxl_defbool_val(b_info->device_model_stubdomain)) {
Signature · 1 line
1.7.10.4
Acked-by on v3 6/6
#10 lore raw

Re: [PATCH v3 6/6] libxl: assign a default ssidref (XSM label) to guests

Quoted 8 lines · Ian Campbell

We have now arranged for SECINITSID_DOMU and SECINITSID_DOMDM to be defined (correspondng to system_u:system_r:domU_t and system_u:system_r:dm_dom_t respectively in the default policy). Use these as the default for the SSID of every (stub)domain.

Quoted 45 lines

---
v2: Set ssidref rather than label. It is no longer necessary to
reorder things in libxl.c.
v3: Set device_model_ssidref too if stubdoms are enabled.
I didn't apply Wei's ack due to this change.

---
 tools/libxl/libxl_create.c |    9 +++++++++
 1 file changed, 9 insertions(+)
tools/libxl/libxl_create.c +9 -0
index f0da7dc..853c252 100644
@@ -25,6 +25,8 @@
 #include <xen/hvm/hvm_info_table.h>
 #include <xen/hvm/e820.h>
 
+#include <xen-xsm/flask/flask.h>
+
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                          libxl_domain_create_info *c_info)
 {
@@ -42,6 +44,9 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
     libxl_defbool_setdefault(&c_info->run_hotplug_scripts, true);
     libxl_defbool_setdefault(&c_info->driver_domain, false);
 
+    if (!c_info->ssidref)
+        c_info->ssidref = SECINITSID_DOMU;
+
     return 0;
 }
 
@@ -111,6 +116,10 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
 
     libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
 
+    if (libxl_defbool_val(b_info->device_model_stubdomain) &&
+        !b_info->device_model_ssidref)
+        b_info->device_model_ssidref = SECINITSID_DOMDM;
+
     if (!b_info->device_model_version) {
         if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
             if (libxl_defbool_val(b_info->device_model_stubdomain)) {
Signature · 1 line
1.7.10.4
Acked-by on v3 6/6
#11 lore raw

Re: [PATCH v3 6/6] libxl: assign a default ssidref (XSM label) to guests

In reply to Ian Campbell
Quoted 6 lines · Ian Campbell

We have now arranged for SECINITSID_DOMU and SECINITSID_DOMDM to be defined (correspondng to system_u:system_r:domU_t and system_u:system_r:dm_dom_t respectively in the default policy). Use these as the default for the SSID of every (stub)domain.

#12 lore raw

Re: [PATCH v3 6/6] libxl: assign a default ssidref (XSM label) to guests

Quoted 9 lines · Daniel De Graaf
Quoted 6 lines · Ian Campbell

We have now arranged for SECINITSID_DOMU and SECINITSID_DOMDM to be defined (correspondng to system_u:system_r:domU_t and system_u:system_r:dm_dom_t respectively in the default policy). Use these as the default for the SSID of every (stub)domain.

Thanks, all applied with Wei and your acks.

Ian.

#13 lore raw
In reply to Ian Campbell
Quoted 7 lines · Ian Campbell

Compared with v3 this uses Daniel's more comprehensive policy patch and adds a default ssidref for stubdoms too.

Tested with and without XSM enabled for normal guests and HVM guests with qemu in dom0. Stubdoms appeared to be broken in the base case, so I haven't tested that really.

Which changeset are you based this series on? I thought I fixed QEMU stubdom sometime ago. Maybe I need to have a look at that again.

Wei.

Quoted 4 lines

Ian.

#14 lore raw
In reply to Ian Campbell
Quoted 6 lines · Ian Campbell

Compared with v3 this uses Daniel's more comprehensive policy patch and adds a default ssidref for stubdoms too.

Tested with and without XSM enabled for normal guests and HVM guests with qemu in dom0. Stubdoms appeared to be broken in the base case, so I haven't tested that really.

I rebased onto new staging (no changes needed) and now stubdoms seem to work again and look to have been correctly labelled using the new defaults:

# xl list -Z
Name                                        ID   Mem VCPUs	State	Time(s)   Security Label
Domain-0                                     0   511     8     r-----      14.4 system_u:system_r:dom0_t
debianhvm.guest.osstest                      1   768     2     -b----       5.7 system_u:system_r:domU_t
debianhvm.guest.osstest-dm                   2    32     1     -b----       4.0 system_u:system_r:dm_dom_t

Ian.

#15 lore raw
Quoted 12 lines · Ian Campbell
Quoted 6 lines · Ian Campbell

Compared with v3 this uses Daniel's more comprehensive policy patch and adds a default ssidref for stubdoms too.

Tested with and without XSM enabled for normal guests and HVM guests with qemu in dom0. Stubdoms appeared to be broken in the base case, so I haven't tested that really.

I rebased onto new staging (no changes needed) and now stubdoms seem to work again and look to have been correctly labelled using the new defaults:

Quoted 6 lines
# xl list -Z
Name                                        ID   Mem VCPUs	State	Time(s)   Security Label
Domain-0                                     0   511     8     r-----      14.4 system_u:system_r:dom0_t
debianhvm.guest.osstest                      1   768     2     -b----       5.7 system_u:system_r:domU_t
debianhvm.guest.osstest-dm                   2    32     1     -b----       4.0 system_u:system_r:dm_dom_t

Great!

Quoted 2 lines

Ian.