From f70d712e4f505f5c5b50ae17f4f023d20a667568 Mon Sep 17 00:00:00 2001 From: José Bollo Date: Wed, 24 Jan 2018 11:38:43 +0100 Subject: Integrate parts of meta-intel-iot-security MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds the recipes of the sub layers - meta-security-framework - meta-security-smack Change-Id: I618608008a3b3d1d34adb6e38048110f13ac0643 Signed-off-by: José Bollo --- .../recipes-connectivity/bluez5/bluez5_%.bbappend | 55 ++++++++++++++++++++++ .../connman/connman_%.bbappend | 32 +++++++++++++ 2 files changed, 87 insertions(+) create mode 100644 meta-security/recipes-connectivity/bluez5/bluez5_%.bbappend create mode 100644 meta-security/recipes-connectivity/connman/connman_%.bbappend (limited to 'meta-security/recipes-connectivity') diff --git a/meta-security/recipes-connectivity/bluez5/bluez5_%.bbappend b/meta-security/recipes-connectivity/bluez5/bluez5_%.bbappend new file mode 100644 index 000000000..c62842d5b --- /dev/null +++ b/meta-security/recipes-connectivity/bluez5/bluez5_%.bbappend @@ -0,0 +1,55 @@ +# Recent bluez5 releases started limiting the capabilities of +# bluetoothd. When running on a Smack-enabled system, that change has the +# effect that bluetoothd can no longer create the input device under +# /sys because bluez5 running with label "System" has no write +# access to that. +# +# It works when running as normal root with unrestricted capabilities +# because then CAP_MAC_OVERRIDE (a Smack-specific capability) allows +# the process to ignore Smack rules. +# +# We need to ensure that bluetoothd still has that capability. +# +# To fix the issue, Patick and Casey(the Smack architect) had a talk +# about it in Ostro dev mail list. Casey has some ideas about the issue: +# "Turning off privilege is a great thing to do *so long as you don't +# really need the privilege*. In this case you really need it. +# The application package isn't written to account for Smack's use of +# CAP_MAC_OVERRIDE as the mechanism for controlling this dangerous operation. +# Yes, it would be possible to change /proc to change the Smack label on +# that particular file, but that might open other paths for exploit. +# I say give the program the required capability. The program maintainer +# may well say change the kernel handling of /proc. You're stuck in the +# middle, as both work the way they're intended and hence the system +# doesn't work. :( There isn't a way to make this work without "loosening" +# something." +# Therefore, when we we run the program with CAP_MAC_OVERRIDE, +# the whole reason for having capabilities is so the we can give a +# process the ability to bypass one kind of check without giving it the +# ability to bypass other, unrelated checks. A process with +# CAP_MAC_OVERRIDE is still constrained by the file mode bits. +# We was overly worried about granting that capability. +# When it has no other effect than excluding a process from Smack MAC enforcement, +# then adding to the process seems like the right solution for now. +# +# The conclusion from Patick and Casey is that the Smack architect give the key point +# that this is the solution preferred. +# +# Because the solution is to some extend specific to the environment +# in which connmand runs, this change is not submitted upstream +# and it can be overridden by a distro via FIX_BLUEZ5_CAPABILITIES. +# +# The related patch has been submitted to upstream too. +# upstream link: http://permalink.gmane.org/gmane.linux.bluez.kernel/67993 + +FIX_BLUEZ5_CAPABILITIES ??= "" +FIX_BLUEZ5_CAPABILITIES_with-lsm-smack ??= "fix_bluez5_capabilities" +do_install[postfuncs] += "${FIX_BLUEZ5_CAPABILITIES}" + +fix_bluez5_capabilities () { + service="${D}/${systemd_unitdir}/system/bluetooth.service" + if [ -f "$service" ] && + grep -q '^CapabilityBoundingSet=' "$service"; then + sed -i -e 's/^CapabilityBoundingSet=/CapabilityBoundingSet=CAP_MAC_OVERRIDE /' "$service" + fi +} diff --git a/meta-security/recipes-connectivity/connman/connman_%.bbappend b/meta-security/recipes-connectivity/connman/connman_%.bbappend new file mode 100644 index 000000000..f66c1e79b --- /dev/null +++ b/meta-security/recipes-connectivity/connman/connman_%.bbappend @@ -0,0 +1,32 @@ +# Recent ConnMan releases started limiting the capabilities of +# ConnMan. When running on a Smack-enabled system, that change has the +# effect that connmand can no longer change network settings under +# /proc/net because the Smack label of /proc is "_", and connmand +# running with label "System" has no write access to that. +# +# It works when running as normal root with unrestricted capabilities +# because then CAP_MAC_OVERRIDE (a Smack-specific capability) allows +# the process to ignore Smack rules. +# +# We need to ensure that connmand still has that capability. +# +# The alternative would be to set up fine-grained labelling of +# /proc with corresponding rules, which is considerably more work +# and also may depend on kernel changes (like supporting smackfsroot +# for procfs, which seems to be missing at the moment). +# +# Because the solution is to some extend specific to the environment +# in which connmand runs, this change is not submitted upstream +# and it can be overridden by a distro via FIX_CONNMAN_CAPABILITIES. + +FIX_CONNMAN_CAPABILITIES ??= "" +FIX_CONNMAN_CAPABILITIES_with-lsm-smack ??= "fix_connman_capabilities" +do_install[postfuncs] += "${FIX_CONNMAN_CAPABILITIES}" + +fix_connman_capabilities () { + service="${D}/${systemd_unitdir}/system/connman.service" + if [ -f "$service" ] && + grep -q '^CapabilityBoundingSet=' "$service"; then + sed -i -e 's/^CapabilityBoundingSet=/CapabilityBoundingSet=CAP_MAC_OVERRIDE /' "$service" + fi +} -- cgit 1.2.3-korg