picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

man: document the new RestrictSUIDSGID= setting

This commit is contained in:
Lennart Poettering 2019-03-20 19:45:32 +01:00
parent 9d880b70ba
commit 7445db6eb7
2 changed files with 30 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
docs/TRANSIENT-SETTINGS.md
View File

@ -155,6 +155,7 @@ All execution-related settings are available for transient units.
✓ MemoryDenyWriteExecute=
✓ RestrictNamespaces=
✓ RestrictRealtime=
✓ RestrictSUIDSGID=
✓ RestrictAddressFamilies=
✓ LockPersonality=
✓ LimitCPU=

41
man/systemd.exec.xml
View File

@ -379,18 +379,19 @@ 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
<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> 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>
@ -1392,6 +1393,22 @@ RestrictNamespaces=~cgroup net</programlisting>
that actually require them. Defaults to off.</para></listitem>
</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). Defaults to off.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>RemoveIPC=</varname></term>