-
Notifications
You must be signed in to change notification settings - Fork 15
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
4 changed files
with
198 additions
and
33 deletions.
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>Secure &systemd; services</title> | ||
| <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> | ||
| <meta name="maintainer" content="[email protected]" its:translate="no"/> | ||
| </info> | ||
| <section xml:id="how-it-works-securing-with-systemd"> | ||
| <title>How does securing services with &systemd; work?</title> | ||
| <para> | ||
| There are several methods to secure processes and applications that you can use | ||
| simultaneously. For example, confining with &selnx; <phrase os="sles">or &aa; </phrase>is | ||
| recommended. &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. | ||
| </para> | ||
| </section> | ||
|
|
||
| <section xml:id="benefits-securing-with-systemd"> | ||
| <title>Benefits of securing services</title> | ||
| <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. | ||
| 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. | ||
| 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> | ||
| <para>Use the command <command>systemd-analyze security</command> to analyze the security settings of a | ||
| &systemd; service. For example: </para> | ||
| <screen> | ||
| 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> | ||
| <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> | ||
| <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> |