DOCTEAM-1303: adds securing related topics to article #467
There are no files selected for viewing
This file contains hidden or 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 hidden or 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>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,31 @@ | |
| 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>Upon checking the security settings, the command 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 hidden or 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,164 @@ | ||||||
| <?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 the <command>systemd-analyze security</command> command to analyze the security settings of a &systemd; service. | ||||||
| The <literal>security</literal> option analyzes 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> | ||||||
|
|
||||||
| <para><emphasis>How to improve the overall exposure</emphasis></para> | ||||||
|
There was a problem hiding this comment. I would start the second section here (with a title like 'How to improve the overall exposure' or ' How to harden systemd services). Looking at the PDF, |
||||||
| <para>If you get <emphasis>9.6 UNSAFE</emphasis>, you can use <literal>[Section]</literal> part of the service definition file to add any of the below options. For example:</para> | ||||||
|
There was a problem hiding this comment.
Suggested change
There was a problem hiding this comment. I'm not 100% sure if it should be |
||||||
| <screen> | ||||||
|
There was a problem hiding this comment. I would wrap the screen (plus the other available options) into an |
||||||
| [Service] | ||||||
| NoNewPrivileges=yes | ||||||
| PrivateTmp=yes | ||||||
| PrivateNetwork=yes | ||||||
| InaccessibleDirectories=/home | ||||||
| ..... | ||||||
| </screen> | ||||||
| <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> | ||||||
| <title>The <command>pscap</command> command tool</title> | ||||||
| <para> | ||||||
| To easily identify which processes on your system retain which capabilities, use the | ||||||
| <command>pscap</command> command tool from the <package>libcap-ng-utils</package> package. | ||||||
| </para> | ||||||
| </tip> | ||||||
|
|
||||||
| <para> | ||||||
| The <literal>~</literal> prefix inverts the meaning of the option—. Instead of | ||||||
| listing all capabilities that the service retains, you can list the ones it does not | ||||||
| retain: | ||||||
| </para> | ||||||
| <screen>... | ||||||
| [Service] | ||||||
| CapabilityBoundingSet=~CAP_SYS_PTRACE | ||||||
| ...</screen> | ||||||
|
|
||||||
| </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> | ||||||
| <para>These are some options you can use.</para> | ||||||
| </topic> | ||||||
|
There was a problem hiding this comment. Is adding the directives everything there is to it? No further steps required like restarting the daemon or the systemd service? And how about testing the new settings (e.g. controlling the logs for any errors or denied operations to make sure that the new restrictions haven't broken the service's legitimate operations)? This would fit in nicely with the next topic, debugging systemd options. |
||||||
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.
Uh oh!
There was an error while loading. Please reload this page.
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.
I would subdivide this file into two sections, one for
<systemd-analyze security>and the second one for improving the overall exposure. Because the second part is at least equally important (if not more important), and it currently does not get the same 'weight' like the first part.