On 1/10/20 12:41 PM, Stephen Smalley wrote:
On 1/10/20 11:55 AM, Paul Moore wrote:
On Fri, Jan 10, 2020 at 9:20 AM Christian Göttsche
<cgzones@xxxxxxxxxxxxxx> wrote:
Support a SELinux overhaul of systemd by adding a policy capability.
The systemd patch can be found at
https://github.com/systemd/systemd/pull/10023
and has NOT yet been accepted.
This is just a rfc to test the water.
---
security/selinux/include/security.h | 1 +
security/selinux/ss/services.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
Generally the SELinux policy capabilities are reserved for *kernel*
changes that potentially break compatibility with existing SELinux
policies. I'm probably not the best person to talk about
tricks/conventions used to do similar things in userspace, but you've
come to the right place :)
It was my suggestion to use policy capabilities for this. There is no
separate mechanism for supporting major changes to userspace SELinux
permission checks in a backward-compatible manner. Userspace already
relies upon /sys/fs/selinux/{deny_unknown,reject_unknown} to get the
handle_unknown setting from the kernel policy to decide how to handle
unknown userspace classes/permissions. That however is insufficient for
these changes to systemd's permission check because they go beyond
introducing new classes and permissions and overhaul the existing
checks. Policy capability seemed like the best way to do it, and
getting it from the kernel is consistent with the fact that we are also
getting the userspace classes/perms from the kernel via
/sys/fs/selinux/class and the userspace access decisions from the kernel
via /sys/fs/selinux/access (through the libselinux AVC, typically).
As to why we keep the userspace policy as part of the kernel policy and
not as a separate entity:
- It allows us to provide an effective atomicity in policy changes that
may span both kernel and userspace components,
- There is significant overlap between the contexts used in the kernel
and userspace policies, since most userspace policy enforcers are using
contexts obtained from the kernel for the subject (e.g.
SO_PEERSEC/getpeercon) or for the object (e.g. getfilecon),
- Policy lookups via /sys/fs/selinux/access are more efficient than
performing an IPC to a userspace security server. Of course, in both
cases, we try to maximize use of the libselinux AVC first to avoid
needing to perform the policy lookup at all.
There were experiments done with introducing support for userspace
security server(s) for things like XACE/XSELinux and it was found to be
unsatisfying both performance and security-wise.
There are still cases where we would recommend userspace security
server(s), such as when the userspace component is implementing a policy
entirely distinct from that of the kernel (e.g. a remote document server
implementing RaDAC policies, as in one of our earlier experimental
research projects), but not for things like systemd.
diff --git a/security/selinux/include/security.h
b/security/selinux/include/security.h
index ecdd610e6449..2853e462977f 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -79,6 +79,7 @@ enum {
POLICYDB_CAPABILITY_ALWAYSNETWORK,
POLICYDB_CAPABILITY_CGROUPSECLABEL,
POLICYDB_CAPABILITY_NNP_NOSUID_TRANSITION,
+ POLICYDB_CAPABILITY_SYSTEMD_OVERHAUL,
__POLICYDB_CAPABILITY_MAX
};
#define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX - 1)
diff --git a/security/selinux/ss/services.c
b/security/selinux/ss/services.c
index 55cf42945cba..cb50e187b181 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -73,7 +73,8 @@ const char
*selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
"extended_socket_class",
"always_check_network",
"cgroup_seclabel",
- "nnp_nosuid_transition"
+ "nnp_nosuid_transition",
+ "systemd_overhaul"
};
static struct selinux_ss selinux_ss;
--
2.24.1
