From d11fdacaf3c804b60dfe8371062f34ac2b624ac9 Mon Sep 17 00:00:00 2001 From: Jan Synacek Date: Fri, 13 Sep 2019 09:23:32 +0200 Subject: [PATCH] man: document systemd-analyze security (cherry-picked from commit ee93c1e664a7bbc59f1578e285c871999507b14d) Resolves: #1750343 --- man/systemd-analyze.xml | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml index 7aa10fc68e..f3b595880f 100644 --- a/man/systemd-analyze.xml +++ b/man/systemd-analyze.xml @@ -106,6 +106,12 @@ service-watchdogs BOOL + + systemd-analyze + OPTIONS + security + UNIT + @@ -253,6 +259,29 @@ NAutoVTs=8 systemd.service5. The hardware watchdog is not affected by this setting. + systemd-analyze security 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. + If no command is passed, systemd-analyze time is implied.