diff options
Diffstat (limited to 'man/systemd.exec.xml')
| -rw-r--r-- | man/systemd.exec.xml | 49 |
1 files changed, 35 insertions, 14 deletions
diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml index f8c46a2995..688147ea32 100644 --- a/man/systemd.exec.xml +++ b/man/systemd.exec.xml @@ -252,7 +252,9 @@ of the service, and hence the lifetime of the dynamic user/group. Since <filename>/tmp</filename> and <filename>/var/tmp</filename> are usually the only world-writable directories on a system this ensures that a unit making use of dynamic user/group allocation cannot leave files around after unit - termination. Moreover <varname>ProtectSystem=strict</varname> and + termination. Furthermore <varname>NoNewPrivileges=</varname> and <varname>RestrictSUIDSGID=</varname> + are implicitly enabled to ensure that processes invoked cannot take benefit or create SUID/SGID files + or directories. Moreover <varname>ProtectSystem=strict</varname> and <varname>ProtectHome=read-only</varname> are implied, thus prohibiting the service to write to arbitrary file system locations. In order to allow the service to write to certain directories, they have to be whitelisted using <varname>ReadWritePaths=</varname>, but care must be taken so that @@ -379,19 +381,21 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting> <varlistentry> <term><varname>NoNewPrivileges=</varname></term> - <listitem><para>Takes a boolean argument. If true, ensures that the service process and all its children can - never gain new privileges through <function>execve()</function> (e.g. via setuid or setgid bits, or filesystem - capabilities). This is the simplest and most effective way to ensure that a process and its children can never - elevate privileges again. Defaults to false, but certain settings override this and ignore the value of this - setting. This is the case when <varname>SystemCallFilter=</varname>, - <varname>SystemCallArchitectures=</varname>, <varname>RestrictAddressFamilies=</varname>, - <varname>RestrictNamespaces=</varname>, <varname>PrivateDevices=</varname>, - <varname>ProtectKernelTunables=</varname>, <varname>ProtectKernelModules=</varname>, - <varname>MemoryDenyWriteExecute=</varname>, <varname>RestrictRealtime=</varname>, or - <varname>LockPersonality=</varname> are specified. Note that even if this setting is overridden by them, - <command>systemctl show</command> shows the original value of this setting. Also see - <ulink url="https://www.kernel.org/doc/html/latest/userspace-api/no_new_privs.html">No New Privileges - Flag</ulink>. </para></listitem> + <listitem><para>Takes a boolean argument. If true, ensures that the service process and all its + children can never gain new privileges through <function>execve()</function> (e.g. via setuid or + setgid bits, or filesystem capabilities). This is the simplest and most effective way to ensure that + a process and its children can never elevate privileges again. Defaults to false, but certain + settings override this and ignore the value of this setting. This is the case when + <varname>SystemCallFilter=</varname>, <varname>SystemCallArchitectures=</varname>, + <varname>RestrictAddressFamilies=</varname>, <varname>RestrictNamespaces=</varname>, + <varname>PrivateDevices=</varname>, <varname>ProtectKernelTunables=</varname>, + <varname>ProtectKernelModules=</varname>, <varname>MemoryDenyWriteExecute=</varname>, + <varname>RestrictRealtime=</varname>, <varname>RestrictSUIDSGID=</varname>, + <varname>DynamicUser=</varname> or <varname>LockPersonality=</varname> are specified. Note that even + if this setting is overridden by them, <command>systemctl show</command> shows the original value of + this setting. Also see <ulink + url="https://www.kernel.org/doc/html/latest/userspace-api/no_new_privs.html">No New Privileges + Flag</ulink>.</para></listitem> </varlistentry> <varlistentry> @@ -1393,6 +1397,23 @@ RestrictNamespaces=~cgroup net</programlisting> </varlistentry> <varlistentry> + <term><varname>RestrictSUIDSGID=</varname></term> + + <listitem><para>Takes a boolean argument. If set, any attempts to set the set-user-ID (SUID) or + set-group-ID (SGID) bits on files or directories will be denied (for details on these bits see + <citerefentry + project='man-pages'><refentrytitle>inode</refentrytitle><manvolnum>7</manvolnum></citerefentry>). If + running in user mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> + capability (e.g. setting <varname>User=</varname>), <varname>NoNewPrivileges=yes</varname> is + implied. As the SUID/SGID bits are mechanisms to elevate privileges, and allows users to acquire the + identity of other users, it is recommended to restrict creation of SUID/SGID files to the few + programs that actually require them. Note that this restricts marking of any type of file system + object with these bits, including both regular files and directories (where the SGID is a different + meaning than for files, see documentation). This option is implied if <varname>DynamicUser=</varname> + is enabled. Defaults to off.</para></listitem> + </varlistentry> + + <varlistentry> <term><varname>RemoveIPC=</varname></term> <listitem><para>Takes a boolean parameter. If set, all System V and POSIX IPC objects owned by the user and |