|
Brian Stinson |
2593d8 |
From d11fdacaf3c804b60dfe8371062f34ac2b624ac9 Mon Sep 17 00:00:00 2001
|
|
Brian Stinson |
2593d8 |
From: Jan Synacek <jsynacek@redhat.com>
|
|
Brian Stinson |
2593d8 |
Date: Fri, 13 Sep 2019 09:23:32 +0200
|
|
Brian Stinson |
2593d8 |
Subject: [PATCH] man: document systemd-analyze security
|
|
Brian Stinson |
2593d8 |
|
|
Brian Stinson |
2593d8 |
(cherry-picked from commit ee93c1e664a7bbc59f1578e285c871999507b14d)
|
|
Brian Stinson |
2593d8 |
|
|
Brian Stinson |
2593d8 |
Resolves: #1750343
|
|
Brian Stinson |
2593d8 |
---
|
|
Brian Stinson |
2593d8 |
man/systemd-analyze.xml | 29 +++++++++++++++++++++++++++++
|
|
Brian Stinson |
2593d8 |
1 file changed, 29 insertions(+)
|
|
Brian Stinson |
2593d8 |
|
|
Brian Stinson |
2593d8 |
diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml
|
|
Brian Stinson |
2593d8 |
index 7aa10fc68e..f3b595880f 100644
|
|
Brian Stinson |
2593d8 |
--- a/man/systemd-analyze.xml
|
|
Brian Stinson |
2593d8 |
+++ b/man/systemd-analyze.xml
|
|
Brian Stinson |
2593d8 |
@@ -106,6 +106,12 @@
|
|
Brian Stinson |
2593d8 |
<arg choice="plain">service-watchdogs</arg>
|
|
Brian Stinson |
2593d8 |
<arg choice="opt"><replaceable>BOOL</replaceable></arg>
|
|
Brian Stinson |
2593d8 |
</cmdsynopsis>
|
|
Brian Stinson |
2593d8 |
+ <cmdsynopsis>
|
|
Brian Stinson |
2593d8 |
+ <command>systemd-analyze</command>
|
|
Brian Stinson |
2593d8 |
+ <arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
Brian Stinson |
2593d8 |
+ <arg choice="plain">security</arg>
|
|
Brian Stinson |
2593d8 |
+ <arg choice="plain" rep="repeat"><replaceable>UNIT</replaceable></arg>
|
|
Brian Stinson |
2593d8 |
+ </cmdsynopsis>
|
|
Brian Stinson |
2593d8 |
</refsynopsisdiv>
|
|
Brian Stinson |
2593d8 |
|
|
Brian Stinson |
2593d8 |
<refsect1>
|
|
Brian Stinson |
2593d8 |
@@ -253,6 +259,29 @@ NAutoVTs=8
|
|
Brian Stinson |
2593d8 |
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
|
Brian Stinson |
2593d8 |
The hardware watchdog is not affected by this setting.</para>
|
|
Brian Stinson |
2593d8 |
|
|
Brian Stinson |
2593d8 |
+ <para><command>systemd-analyze security</command> analyzes the security and sandboxing settings of one or more
|
|
Brian Stinson |
2593d8 |
+ specified service units. If at least one unit name is specified the security settings of the specified service
|
|
Brian Stinson |
2593d8 |
+ units are inspected and a detailed analysis is shown. If no unit name is specified, all currently loaded,
|
|
Brian Stinson |
2593d8 |
+ long-running service units are inspected and a terse table with results shown. The command checks for various
|
|
Brian Stinson |
2593d8 |
+ security-related service settings, assigning each a numeric "exposure level" value, depending on how important a
|
|
Brian Stinson |
2593d8 |
+ setting is. It then calculates an overall exposure level for the whole unit, which is an estimation in the range
|
|
Brian Stinson |
2593d8 |
+ 0.0…10.0 indicating how exposed a service is security-wise. High exposure levels indicate very little applied
|
|
Brian Stinson |
2593d8 |
+ sandboxing. Low exposure levels indicate tight sandboxing and strongest security restrictions. Note that this only
|
|
Brian Stinson |
2593d8 |
+ analyzes the per-service security features systemd itself implements. This means that any additional security
|
|
Brian Stinson |
2593d8 |
+ mechanisms applied by the service code itself are not accounted for. The exposure level determined this way should
|
|
Brian Stinson |
2593d8 |
+ not be misunderstood: a high exposure level neither means that there is no effective sandboxing applied by the
|
|
Brian Stinson |
2593d8 |
+ service code itself, nor that the service is actually vulnerable to remote or local attacks. High exposure levels
|
|
Brian Stinson |
2593d8 |
+ do indicate however that most likely the service might benefit from additional settings applied to them. Please
|
|
Brian Stinson |
2593d8 |
+ note that many of the security and sandboxing settings individually can be circumvented — unless combined with
|
|
Brian Stinson |
2593d8 |
+ others. For example, if a service retains the privilege to establish or undo mount points many of the sandboxing
|
|
Brian Stinson |
2593d8 |
+ options can be undone by the service code itself. Due to that is essential that each service uses the most
|
|
Brian Stinson |
2593d8 |
+ comprehensive and strict sandboxing and security settings possible. The tool will take into account some of these
|
|
Brian Stinson |
2593d8 |
+ combinations and relationships between the settings, but not all. Also note that the security and sandboxing
|
|
Brian Stinson |
2593d8 |
+ settings analyzed here only apply to the operations executed by the service code itself. If a service has access to
|
|
Brian Stinson |
2593d8 |
+ an IPC system (such as D-Bus) it might request operations from other services that are not subject to the same
|
|
Brian Stinson |
2593d8 |
+ restrictions. Any comprehensive security and sandboxing analysis is hence incomplete if the IPC access policy is
|
|
Brian Stinson |
2593d8 |
+ not validated too.</para>
|
|
Brian Stinson |
2593d8 |
+
|
|
Brian Stinson |
2593d8 |
<para>If no command is passed, <command>systemd-analyze
|
|
Brian Stinson |
2593d8 |
time</command> is implied.</para>
|
|
Brian Stinson |
2593d8 |
|