Merge pull request #10701 from poettering/analyze-security

systemd-analyze: add a new "security" verb for analyzing unit sandboxing options

TODO

@@ -25,6 +25,10 @@ Features:
 
 * when we fork off generators and such, lower LIMIT_NOFILE soft limit to 1K
 
+* rework seccomp/nnp logic that that even if User= is used in combination with
+  a seccomp option we don't have to set NNP. For that, change uid first whil
+  keeping CAP_SYS_ADMIN, then apply seccomp, the drop cap.
+
 * add a concept for automatically loading per-unit secrets off disk and
   inserting them into the kernel keyring. Maybe SecretsDirectory= similar to
   ConfigurationDirectory=.
@@ -49,6 +53,9 @@ Features:
 
 * set memory.oom.group in cgroupsv2 for all leaf cgroups (kernel v4.19+)
 
+* add a new syscall group "@esoteric" for more esoteric stuff such as bpf() and
+  usefaultd() and make systemd-analyze check for it.
+
 * drop umask() calls and suchlike from our generators, pid1 should set things up correctly anyway
 
 * paranoia: whenever we process passwords, call mlock() on the memory
@@ -290,9 +297,6 @@ Features:
 * beef up pam_systemd to take unit file settings such as cgroups properties as
   parameters
 
-* a new "systemd-analyze security" tool outputting a checklist of security
-  features a service does and does not implement
-
 * maybe hook of xfs/ext4 quotactl() with services? i.e. automatically manage
   the quota of a the user indicated in User= via unit file settings, like the
   other resource management concepts. Would mix nicely with DynamicUser=1. Or

docs/ENVIRONMENT.md

@@ -46,9 +46,14 @@ All tools:
   are understood, too (us, ms, s, min, h, d, w, month, y). If it is not set or set
   to 0, then the built-in default is used.
 
-* `$SYSTEMD_MEMPOOL=0` — if set the internal memory caching logic employed by
+* `$SYSTEMD_MEMPOOL=0` — if set, the internal memory caching logic employed by
   hash tables is turned off, and libc malloc() is used for all allocations.
 
+* `$SYSTEMD_EMOJI=0` — if set, tools such as "systemd-analyze security" will
+  not output graphical smiley emojis, but ASCII alternatives instead. Note that
+  this only controls use of Unicode emoji glyphs, and has no effect on other
+  Unicode glyphs.
+
 systemctl:
 
 * `$SYSTEMCTL_FORCE_BUS=1` — if set, do not connect to PID1's private D-Bus

man/systemd-analyze.xml

@@ -112,6 +112,12 @@
       <arg choice="plain">timespan</arg>
       <arg choice="plain" rep="repeat"><replaceable>SPAN</replaceable></arg>
     </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">security</arg>
+      <arg choice="plain" rep="repeat"><replaceable>UNIT</replaceable></arg>
+    </cmdsynopsis>
   </refsynopsisdiv>
 
   <refsect1>
@@ -263,6 +269,29 @@ NAutoVTs=8
     The time span should adhere to the same syntax documented in <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
     Values without associated magnitudes are parsed as seconds.</para>
 
+    <para><command>systemd-analyze security</command> analyzes the security and sandboxing settings of one or more
+    specified service units. If at least one unit name is specified the security settings of the specified service
+    units are inspected and a detailed analysis is shown. If no unit name is specified, all currently loaded,
+    long-running service units are inspected and a terse table with results shown. The command checks for various
+    security-related service settings, assigning each a numeric "exposure level" value, depending on how important a
+    setting is. It then calculates an overall exposure level for the whole unit, which is an estimation in the range
+    0.0…10.0 indicating how exposed a service is security-wise. High exposure levels indicate very little applied
+    sandboxing. Low exposure levels indicate tight sandboxing and strongest security restrictions. Note that this only
+    analyzes the per-service security features systemd itself implements. This means that any additional security
+    mechanisms applied by the service code itself are not accounted for. The exposure level determined this way should
+    not be misunderstood: a high exposure level neither means that there is no effective sandboxing applied by the
+    service code itself, nor that the service is actually vulnerable to remote or local attacks. High exposure levels
+    do indicate however that most likely the service might benefit from additional settings applied to them. Please
+    note that many of the security and sandboxing settings individually can be circumvented — unless combined with
+    others. For example, if a service retains the privilege to establish or undo mount points many of the sandboxing
+    options can be undone by the service code itself. Due to that is essential that each service uses the most
+    comprehensive and strict sandboxing and security settings possible. The tool will take into account some of these
+    combinations and relationships between the settings, but not all. Also note that the security and sandboxing
+    settings analyzed here only apply to the operations executed by the service code itself. If a service has access to
+    an IPC system (such as D-Bus) it might request operations from other services that are not subject to the same
+    restrictions. Any comprehensive security and sandboxing analysis is hence incomplete if the IPC access policy is
+    not validated too.</para>
+
     <para>If no command is passed, <command>systemd-analyze
     time</command> is implied.</para>