Security/Tizen 4.X Security options for systemd units

From Tizen Wiki
Jump to: navigation, search

Systemd Security Options

Please refer detail including all other options in and

  • NoNewPrivileges=
If it is set as True, no new privileges (e.g via setuid, setgid or capabilities) are added to a current and inherited processes. If not set, default value is False.
  • SecureBits=
Controls the secure bits set for the executed process.
Takes a space-separated combination of options from the following list: keep-caps, keep-caps-locked, no-setuid-fixup, no-setuid-fixup-locked, noroot, and noroot-locked.
  • SECBIT_KEEP_CAPS (SecureBits=keep-caps)
Setting this flag allows a thread that has one or more 0 UIDs to retain capabilities in its permitted set when it switches all of its UIDs to nonzero values. If this flag is not set, then such a UID switch causes the thread to lose all permitted capabilities. This flag is always cleared on an execve(2).
Note that even with the SECBIT_KEEP_CAPS flag set, the effec‐tive capabilities of a thread are cleared when it switches its effective UID to a nonzero value. However, if the thread has set this flag and its effective UID is already nonzero, and the thread subsequently switches all other UIDs to nonzero values, then the effective capabilities will not be cleared.
The setting of the SECBIT_KEEP_CAPS flag is ignored if the SECBIT_NO_SETUID_FIXUP flag is set. (The latter flag provides a superset of the effect of the former flag.)
This flag provides the same functionality as the older prctl(2) PR_SET_KEEPCAPS operation.
  • SECBIT_NO_SETUID_FIXUP (SecureBits=no-setuid-fixup,)
Setting this flag stops the kernel from adjusting the process's permitted, effective, and ambient capability sets when the thread's effective and filesystem UIDs are switched between zero and nonzero values. (See the subsection Effect of user ID changes on capabilities.)
  • SECBIT_NOROOT (SecureBits=noroot)
If this bit is set, then the kernel does not grant capabili‐ties when a set-user-ID-root program is executed, or when a process with an effective or real UID of 0 calls execve(2).
(See the subsection Capabilities and execution of programs by root.)
  • If "locked" is added, (e.g. keep-caps-locked, no-setuid-fixup-locked, noroot-locked) flag bits would be irreversible.
  • User=, Group=
Set the UNIX user or group that the processes are executed as, respectively. Takes a single user or group name, or a numeric ID as argument. For system services (services run by the system service manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of systemd --user), the default is "root", but User= may be used to specify a different user. For user services of any other user, switching user identity is not permitted, hence the only valid setting is the same user the user's service manager is running as. If no group is set, the default group of the user is used. This setting does not affect commands whose command line is prefixed with "+".
Note that this enforces only weak restrictions on the user/group name syntax, but will generate warnings in many cases where user/group names do not adhere to the following rules: the specified name should consist only of the characters a-z, A-Z, 0-9, "_" and "-", except for the first character which must be one of a-z, A-Z and "_" (i.e. digits and "-" are not permitted as first character). The user/group name must have at least one character, and at most 31. These restrictions are made in order to avoid ambiguities and to ensure user/group names and unit files remain portable among Linux systems. For further details on the names accepted and the names warned about see User/Group Name Syntax.
When used in conjunction with DynamicUser= the user/group name specified is dynamically allocated at the time the service is started, and released at the time the service is stopped — unless it is already allocated statically (see below). If DynamicUser= is not used the specified user and group must have been created statically in the user database no later than the moment the service is started, for example using the sysusers.d(5) facility, which is applied at boot or package install time. If the user does not exist by then program invocation will fail.
If the User= setting is used the supplementary group list is initialized from the specified user's default group list, as defined in the system's user and group database. Additional groups may be configured through the SupplementaryGroups= setting (see below).
  • SupplementaryGroups=
Sets the supplementary Unix groups the processes are executed as. This takes a space-separated list of group names or IDs. This option may be specified more than once, in which case all listed groups are set as supplementary groups. When the empty string is assigned, the list of supplementary groups is reset, and all assignments prior to this one will have no effect. In any way, this option does not override, but extends the list of supplementary groups configured in the system group database for the user. This does not affect commands prefixed with "+".
  • CapabilityBoundingSet=
Controls which capabilities to include in the capability bounding set for the executed process. See capabilities(7) for details. Takes a whitespace-separated list of capability names, e.g. CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. Capabilities listed will be included in the bounding set, all others are removed. If the list of capabilities is prefixed with "~", all but the listed capabilities will be included, the effect of the assignment inverted. Note that this option also affects the respective capabilities in the effective, permitted and inheritable capability sets. If this option is not used, the capability bounding set is not modified on process execution, hence no limits on the capabilities of the process are enforced. This option may appear more than once, in which case the bounding sets are merged by OR, or by AND if the lines are prefixed with "~" (see below). If the empty string is assigned to this option, the bounding set is reset to the empty capability set, and all prior settings have no effect. If set to "~" (without any further argument), the bounding set is reset to the full set of available capabilities, also undoing any previous settings. This does not affect commands prefixed with "+".
if a unit has the following,
     CapabilityBoundingSet=CAP_A CAP_B
     CapabilityBoundingSet=CAP_B CAP_C
then CAP_A, CAP_B, and CAP_C are set.
if the second line is prefixed with "~", e.g.,
     CapabilityBoundingSet=CAP_A CAP_B
     CapabilityBoundingSet=~CAP_B CAP_C
then, only CAP_A is set.
  • Capabilities=
Controls the capabilities(7) set for the executed process. Take a capability string describing the effective, permitted and inherited capability sets as documented in cap_from_text(3). Note that these capability sets are usually influenced (and filtered) by the capabilities attached to the executed file. Due to that CapabilityBoundingSet= is probably a much more useful setting.


  • General Description
For the purpose of performing permission checks, traditional UNIX implementations distinguish two categories of processes: privileged processes (whose effective user ID is 0, referred to as superuser or root), and unprivileged processes (whose effective UID is nonzero). Privileged processes bypass all kernel permission checks, while unprivileged processes are subject to full permission checking based on the process's credentials (usually: effective UID, effective GID, and supplementary group list).
Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute.
  • File Capability Sets
The three file capability sets are:
  • Permitted (formerly known as forced):
These capabilities are automatically permitted to the thread, regardless of the thread's inheritable capabilities.
  • Inheritable (formerly known as allowed):
This set is ANDed with the thread's inheritable set to determine which inheritable capabilities are enabled in the permitted set of the thread after the execve(2).
  • Effective
This is not a set, but rather just a single bit. If this bit is set, then during an execve(2) all of the new permitted capabilities for the thread are also raised in the effective set. If this bit is not set, then after an execve(2), none of the new permitted capabilities is in the new effective set.
Enabling the file effective capability bit implies that any file permitted or inheritable capability that causes a thread to acquire the corresponding permitted capability during an execve(2) (see the transformation rules described below) will also acquire that capability in its effective set. Therefore, when assigning capabilities to a file (setcap(8), cap_set_file(3), cap_set_fd(3)), if we specify the effective flag as being enabled for any capability, then the effective flag must also be specified as enabled for all other capabilities for which the corresponding permitted or inheritable flags is enabled.
  • Transformation of capabilities during execve()
During an execve(2), the kernel calculates the new capabilities of the process using the following algorithm:
     P'(permitted)   = (P(inheritable) & F(inheritable)) |  (F(permitted) & cap_bset)
     P'(effective)   = F(effective) ? P'(permitted) : 0
     P'(inheritable) = P(inheritable)    [i.e., unchanged]
     P         denotes the value of a thread capability set before the execve(2)
     P'        denotes the value of a thread capability set after the execve(2)
     F         denotes a file capability set
     cap_bset  is the value of the capability bounding set
  • Capability Lists
Please refer