DOCTEAM-1303: Securing systemd services #371
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -14,7 +14,8 @@ | |
| xmlns:xlink="http://www.w3.org/1999/xlink" | ||
| xmlns:trans="http://docbook.org/ns/transclusion"> | ||
| <info> | ||
| <title>Introduction to securing &systemd; services</title> | ||
| <meta name="maintainer" content="[email protected]" its:translate="no"/> | ||
| <abstract> | ||
| <para> | ||
| Linux increases its security by separating privileges between individual components of the | ||
|
|
@@ -30,23 +31,32 @@ | |
| them from certain privileges that normal users are allowed to use. | ||
| </para> | ||
| </abstract> | ||
| </info> | ||
|
|
||
| <section xml:id="benefits-securing-with-systemd"> | ||
| <title>Why is securing &systemd; services important?</title> | ||
| <para> | ||
| Securing &systemd; services increases the security of the whole operating system and protects | ||
| sensitive data contained on its file system. With &systemd;, you can configure your system in many ways. | ||
| &systemd; runs as the first process on boot (PID1) which means that it has a lot of power on your Linux environment. | ||
| </para> | ||
| <para>&systemd; can apply additional restrictions to local services by using technologies included in the kernel. | ||
| These restrictions are activated by adding specific options to the systemd service definition and restarting the service. | ||
| &systemd; has a command-line tool <command>systemd-analyze security</command>. This command analyses the services and checks | ||
| if the services are using its security options.</para> | ||
| </section> | ||
| <section xml:id="what-is-systemd-aalyze-security-command"> | ||
| <title>What is the <command>systemd-analyze security</command> command?</title> | ||
| <para> | ||
| The command analyzes the security and sandboxing settings of the specified service units. | ||
| A detailed analysis of the security settings is executed and displayed. | ||
| If a service unit is not specified, all currently loaded, long-running service units are inspected and the results are displayed in a terse table. | ||
| </para> | ||
| <para>The command upon checking the security settings, assigns a numeric value , also known as <emphasis>exposure level</emphasis>. | ||
| This value is dependent on how important a setting is. It then calculates an overall exposure level for the whole unit. This value ranges | ||
| from 0.0-10.0, which is an indicator of how exposed a service is security wise. | ||
| High exposure levels indicate that the service might benefit from additional security settings. | ||
| While low exposure levels indicate tight security restrictions. | ||
| </para> | ||
| </section> | ||
| </topic> | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,166 @@ | ||||||
| <?xml version="1.0" encoding="UTF-8"?> | ||||||
| <!DOCTYPE topic | ||||||
| [ | ||||||
| <!ENTITY % entities SYSTEM "../common/generic-entities.ent"> | ||||||
| %entities; | ||||||
| ]> | ||||||
| <topic xml:id="systemd-example-secure-service" | ||||||
| role="task" xml:lang="en" | ||||||
| xmlns="http://docbook.org/ns/docbook" version="5.2" | ||||||
| xmlns:its="http://www.w3.org/2005/11/its" | ||||||
| xmlns:xi="http://www.w3.org/2001/XInclude" | ||||||
| xmlns:xlink="http://www.w3.org/1999/xlink" | ||||||
| xmlns:trans="http://docbook.org/ns/transclusion"> | ||||||
| <info> | ||||||
| <title>How to analyze the security of a &systemd; service?</title> | ||||||
| <meta name="maintainer" content="[email protected]" its:translate="no"/> | ||||||
| <abstract> | ||||||
| <para> | ||||||
| Use &systemd; to secure and strengthen services using specific directives and verify the same. | ||||||
|
There was a problem hiding this comment. I would specify in the intro already which command you are referring to here (the concrete command is only mentioned in step 4 of the procedure). Maybe even use the same intro like in the following section? |
||||||
| Use the <literal>security</literal> option to analyze the security and the sandboxing settings of one or more specified services. | ||||||
| </para> | ||||||
|
|
||||||
| </abstract> | ||||||
|
|
||||||
| </info> | ||||||
| <procedure> | ||||||
| <step><para>Create a &systemd; service in the <filename>/etc/systemd/system</filename>. </para> | ||||||
| </step> | ||||||
| <step><para>Reload the service files to include the new service:</para> | ||||||
| <screen>&prompt.sudo; systemctl daemon-reload</screen> | ||||||
| </step> | ||||||
| <step><para>Start,enable, and check the status of the service:</para> | ||||||
| <screen>&prompt.sudo; systemctl start <replaceable>SERVICE_NAME</replaceable></screen> | ||||||
| <screen>&prompt.sudo;systemctl enable <replaceable>SERVICE_NAME</replaceable></screen> | ||||||
| <screen>&prompt.sudo; systemctl status <replaceable>SERVICE_NAME</replaceable></screen> | ||||||
|
|
||||||
| </step> | ||||||
| <step><para>Analyze the security settings of the service:</para> | ||||||
| <screen>&prompt.sudo; systemd-analyze security <replaceable>SERVICE_NAME</replaceable></screen> | ||||||
| <para>For example:</para> | ||||||
| <screen>&prompt.sudo; systemd-analyze security test.service | ||||||
| NAME DESCRIPTION EXPOSURE | ||||||
| ✗ PrivateNetwork= Service has access to the host's network 0.5 | ||||||
| ✗ User=/DynamicUser= Service runs as root user 0.4 | ||||||
| ✗ DeviceAllow= Service has no device ACL | ||||||
| ... | ||||||
| → Overall exposure level for test.service: 9.6 UNSAFE 😨 | ||||||
| </screen> | ||||||
| </step> | ||||||
| </procedure> | ||||||
| <section xml:id="improving-overall-exposure"> | ||||||
| <title>How to improve the overall exposure with options?</title> | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
| <para>Use the command <command>systemd-analyze security</command> to analyze the security settings of a | ||||||
| &systemd; service. For example: </para> | ||||||
| <screen> | ||||||
|
There was a problem hiding this comment. It's the same example like in the previous section (which is good in terms of consistency) but if you have a look at the PDF or HTML output both examples follow each other directly (end of p.4 and beginning of p.5). Therefore it looks to reader like content that is duplicated without a good reason. I would rather omit the example output here and instead give show how to run the |
||||||
| NAME DESCRIPTION EXPOSURE | ||||||
| ✗ PrivateNetwork= Service has access to the host's network 0.5 | ||||||
| ✗ User=/DynamicUser= Service runs as root user 0.4 | ||||||
| ✗ DeviceAllow= Service has no device ACL 0.2 | ||||||
| ... | ||||||
| → Overall exposure level for test.service: 9.6 UNSAFE 😨 | ||||||
| </screen> | ||||||
| <para>If you get <emphasis>9.6 UNSAFE</emphasis>, this is not good but you can use the following options to improve the rating.</para> | ||||||
| <variablelist> | ||||||
| <varlistentry> | ||||||
| <term>NoNewPrivileges=yes</term> | ||||||
| <listitem> | ||||||
| <para> | ||||||
| New privileges are not required. | ||||||
| </para> | ||||||
| </listitem> | ||||||
| </varlistentry> | ||||||
| <varlistentry> | ||||||
| <term>PrivateTmp=yes</term> | ||||||
| <listitem> | ||||||
| <para> | ||||||
| Private directory for temporary files. This option provides the service with a private <filename>/tmp</filename> isolated from | ||||||
| the host system's <filename>/tmp</filename>. The shared host <filename>/tmp</filename> | ||||||
| directory is a major source of security problems, such as symlink attacks and DoS | ||||||
| <filename>/tmp</filename> temporary files. | ||||||
| </para> | ||||||
| </listitem> | ||||||
| </varlistentry> | ||||||
| <varlistentry> | ||||||
| <term>PrivateNetwork=yes</term> | ||||||
| <listitem> | ||||||
| <para> | ||||||
| This option isolates the service and its processes from networking. This prevents | ||||||
| external network requests from reaching the protected service. Be aware that certain | ||||||
| services require the network to be operational. | ||||||
| </para> | ||||||
| </listitem> | ||||||
| </varlistentry> | ||||||
| <varlistentry> | ||||||
| <term>InaccessibleDirectories=/home</term> | ||||||
| <listitem> | ||||||
| <para> | ||||||
| This option makes the specified directories inaccessible to the service. This option | ||||||
| narrows the range of directories that can be read or modified by the service, for | ||||||
| example, to secure users' private files. | ||||||
| </para> | ||||||
| </listitem> | ||||||
| </varlistentry> | ||||||
| <varlistentry> | ||||||
| <term>ReadOnlyDirectories=/var</term> | ||||||
| <listitem> | ||||||
| <para> | ||||||
| This option makes the specified directories inaccessible for writing to the service. The | ||||||
| example configuration makes the whole tree below <filename>/var</filename> read-only. | ||||||
| This option prevents the service from damaging the system files. | ||||||
| </para> | ||||||
| </listitem> | ||||||
| </varlistentry> | ||||||
| <varlistentry> | ||||||
| <term>CapabilityBoundingSet=CAP_CHOWN CAP_KILL</term> | ||||||
| <listitem> | ||||||
| <para> | ||||||
| This option restricts the kernel capabilities that a service can retain. In the example | ||||||
| above, only the <literal>CAP_CHOWN</literal> and <literal>CAP_KILL</literal> capabilities | ||||||
| are retained by the service, and the service and any processes it creates cannot obtain | ||||||
| any other capabilities, not even via setuid binaries. | ||||||
| </para> | ||||||
| <tip> | ||||||
|
There was a problem hiding this comment. Our schema does not enforce it but I would add a title to all admonitions (also tips) - makes it easier to spot at first sight what the admonition is about. |
||||||
| <para> | ||||||
| To easily identify which processes on your system retain which capabilities, use the | ||||||
| <command>pscap</command> tool from the <package>libcap-ng-utils</package> package. | ||||||
| </para> | ||||||
| </tip> | ||||||
| <tip> | ||||||
|
There was a problem hiding this comment. This is the second tip right behind the first... I tend to avoid that in order to not annoy the reader. Maybe consider turning the content of one of them into a normal para. |
||||||
| <para> | ||||||
| The <literal>~</literal> prefix inverts the meaning of the option—instead of | ||||||
| listing all capabilities that the service retains, you may list the ones it does not | ||||||
| retain: | ||||||
| </para> | ||||||
| <screen>... | ||||||
| [Service] | ||||||
| CapabilityBoundingSet=~CAP_SYS_PTRACE | ||||||
| ...</screen> | ||||||
| </tip> | ||||||
| </listitem> | ||||||
|
|
||||||
| </varlistentry> | ||||||
| <varlistentry> | ||||||
| <term>LimitNPROC=1, LimitFSIZE=0</term> | ||||||
| <listitem> | ||||||
| <para> | ||||||
| You can use <emphasis>resource limits</emphasis> to apply security limits on services. | ||||||
| Two of them can disable specific operating system features: | ||||||
| <option>RLIMIT_NPROC=1</option> disables precess forking, while | ||||||
| <option>RLIMIT_FSIZE=0</option> disables creating non-empty files on the file system. | ||||||
| </para> | ||||||
| </listitem> | ||||||
| </varlistentry> | ||||||
| <varlistentry> | ||||||
| <term>DeviceAllow=/dev/null rw</term> | ||||||
| <listitem> | ||||||
| <para> | ||||||
| This option limits access to <filename>/dev/null</filename>, disallowing access to any | ||||||
| other device nodes. | ||||||
| </para> | ||||||
| </listitem> | ||||||
| </varlistentry> | ||||||
| </variablelist> | ||||||
| </section> | ||||||
|
|
||||||
| </topic> | ||||||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving the final editing to Daria, but here I stumbled when reading the sentence because the original word order made it hard to understand the sentence at first glance.