diff options
author | Lennart Poettering <lennart@poettering.net> | 2014-06-03 23:41:44 +0200 |
---|---|---|
committer | Lennart Poettering <lennart@poettering.net> | 2014-06-03 23:57:51 +0200 |
commit | 417116f23432073162ebfcb286a7800846482eed (patch) | |
tree | 8e6076d15760c8079deb32eff461e0cc3168fa61 /man | |
parent | 85b5673b337048fa881a5afb1d00d1a7b95950fb (diff) |
core: add new ReadOnlySystem= and ProtectedHome= settings for service units
ReadOnlySystem= uses fs namespaces to mount /usr and /boot read-only for
a service.
ProtectedHome= uses fs namespaces to mount /home and /run/user
inaccessible or read-only for a service.
This patch also enables these settings for all our long-running services.
Together they should be good building block for a minimal service
sandbox, removing the ability for services to modify the operating
system or access the user's private data.
Diffstat (limited to 'man')
-rw-r--r-- | man/systemd.exec.xml | 61 |
1 files changed, 60 insertions, 1 deletions
diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml index 3f27d13c38..3664303491 100644 --- a/man/systemd.exec.xml +++ b/man/systemd.exec.xml @@ -764,7 +764,7 @@ capability sets as documented in <citerefentry><refentrytitle>cap_from_text</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Note that these capability sets are - usually influenced by the capabilities + usually influenced (and filtered) by the capabilities attached to the executed file. Due to that <varname>CapabilityBoundingSet=</varname> @@ -935,6 +935,63 @@ </varlistentry> <varlistentry> + <term><varname>ReadOnlySystem=</varname></term> + + <listitem><para>Takes a boolean + argument. If true, mounts the + <filename>/usr</filename> and + <filename>/boot</filename> directories + read-only for processes invoked by + this unit. This setting ensures that + any modification of the vendor + supplied operating system is + prohibited for the service. It is + recommended to enable this setting for + all long-running services, unless they + are involved with system updates or + need to modify the operating system in + other ways. Note however, that + processes retaining the CAP_SYS_ADMIN + capability can undo the effect of this + setting. This setting is hence + particularly useful for daemons which + have this capability removed, for + example with + <varname>CapabilityBoundingSet=</varname>. Defaults + to off.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ProtectedHome=</varname></term> + + <listitem><para>Takes a boolean + argument or + <literal>read-only</literal>. If true, + the directories + <filename>/home</filename> and + <filename>/run/user</filename> are + made inaccessible and empty for + processes invoked by this unit. If set + to <literal>read-only</literal> the + two directores are made read-only + instead. It is recommended to enable + this setting for all long-running + services (in particular network-facing + one), to ensure they cannot get access + to private user data, unless the + services actually require access to + the user's private data. Note however, + that processes retaining the + CAP_SYS_ADMIN capability can undo the + effect of this setting. This setting + is hence particularly useful for + daemons which have this capability + removed, for example with + <varname>CapabilityBoundingSet=</varname>. Defaults + to off.</para></listitem> + </varlistentry> + + <varlistentry> <term><varname>MountFlags=</varname></term> <listitem><para>Takes a mount @@ -968,6 +1025,8 @@ namespace related options (<varname>PrivateTmp=</varname>, <varname>PrivateDevices=</varname>, + <varname>ReadOnlySystem=</varname>, + <varname>ProtectedHome=</varname>, <varname>ReadOnlyDirectories=</varname>, <varname>InaccessibleDirectories=</varname> and |