Config-Model-Systemd
view release on metacpan or search on metacpan
lib/Config/Model/models/Systemd/Common/Exec.pl view on Meta::CPAN
e.g. C<CAP_SYS_ADMIN>, C<CAP_DAC_OVERRIDE>,
C<CAP_SYS_PTRACE>. Capabilities listed will be included in the bounding set, all
others are removed. If the list of capabilities is prefixed with C<~>, 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 C<OR>, or by
C<AND> if the lines are prefixed with C<~> (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 C<~> (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 C<+>.
Use
L<systemd-analyze(1)>\'s
capability command to retrieve a list of capabilities defined on the local
system.
Example: if a unit has the following,
CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=CAP_B CAP_C
then C<CAP_A>, C<CAP_B>, and
C<CAP_C> are set. If the second line is prefixed with
C<~>, e.g.,
CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=~CAP_B CAP_C
then, only C<CAP_A> is set.',
'type' => 'leaf',
'value_type' => 'uniline'
},
'AmbientCapabilities',
{
'description' => 'Controls which capabilities to include in the ambient capability set for the executed
process. Takes a whitespace-separated list of capability names, e.g. C<CAP_SYS_ADMIN>,
C<CAP_DAC_OVERRIDE>, C<CAP_SYS_PTRACE>. This option may appear more than
once, in which case the ambient capability sets are merged (see the above examples in
C<CapabilityBoundingSet>). If the list of capabilities is prefixed with C<~>,
all but the listed capabilities will be included, the effect of the assignment inverted. If the empty string is
assigned to this option, the ambient capability set is reset to the empty capability set, and all prior
settings have no effect. If set to C<~> (without any further argument), the ambient capability
set is reset to the full set of available capabilities, also undoing any previous settings. Note that adding
capabilities to the ambient capability set adds them to the process\'s inherited capability set.
Ambient capability sets are useful if you want to execute a process as a non-privileged user but
still want to give it some capabilities. Note that, in this case, option C<keep-caps>
is automatically added to C<SecureBits> to retain the capabilities over the user
change. C<AmbientCapabilities> does not affect commands prefixed with
C<+>.',
'type' => 'leaf',
'value_type' => 'uniline'
},
'NoNewPrivileges',
{
'description' => 'Takes a boolean argument. If true, ensures that the service process and all its
children can never gain new privileges through execve() (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. In case the service
will be run in a new mount namespace anyway and SELinux is disabled, all file systems are mounted with
C<MS_NOSUID> flag. Also see L<No New Privileges Flag|https://docs.kernel.org/userspace-api/no_new_privs.html>.
Note that this setting only has an effect on the unit\'s processes themselves (or any processes
directly or indirectly forked off them). It has no effect on processes potentially invoked on request
of them through tools such as L<at(1)>,
L<crontab(1)>,
L<systemd-run(1)>, or
arbitrary IPC services.',
'type' => 'leaf',
'upstream_default' => 'no',
'value_type' => 'boolean',
'write_as' => [
'no',
'yes'
]
},
'SecureBits',
{
'description' => 'Controls the secure bits set for the executed process. Takes a space-separated combination of
options from the following list: C<keep-caps>, C<keep-caps-locked>,
C<no-setuid-fixup>, C<no-setuid-fixup-locked>, C<noroot>, and
C<noroot-locked>. This option may appear more than once, in which case the secure bits are
ORed. If the empty string is assigned to this option, the bits are reset to 0. This does not affect commands
prefixed with C<+>. See L<capabilities(7)> for
details.',
'type' => 'leaf',
'value_type' => 'uniline'
},
'SELinuxContext',
{
'description' => 'Set the SELinux security context of the executed process. If set, this will override the
automated domain transition. However, the policy still needs to authorize the transition. This directive is
ignored if SELinux is disabled. If prefixed by C<->, failing to set the SELinux
security context will be ignored, but it is still possible that the subsequent
execve() may fail if the policy does not allow the transition for the
non-overridden context. This does not affect commands prefixed with C<+>. See
L<setexeccon(3)>
for details.',
'type' => 'leaf',
'value_type' => 'uniline'
},
'AppArmorProfile',
{
'description' => 'Takes a profile name as argument. The process executed by the unit will switch to
this profile when started. Profiles must already be loaded in the kernel, or the unit will fail. If
prefixed by C<->, all errors will be ignored. This setting has no effect if AppArmor
is not enabled. This setting does not affect commands prefixed with C<+>.',
'type' => 'leaf',
'value_type' => 'uniline'
},
'SmackProcessLabel',
{
'description' => 'Takes a C<SMACK64> security label as argument. The process executed by the unit
will be started under this label and SMACK will decide whether the process is allowed to run or not, based on
it. The process will continue to run under the label specified here unless the executable has its own
C<SMACK64EXEC> label, in which case the process will transition to run under that label. When not
specified, the label that systemd is running under is used. This directive is ignored if SMACK is
disabled.
lib/Config/Model/models/Systemd/Common/Exec.pl view on Meta::CPAN
Commands prefixed with C<+> are not subject to filtering. The
execve(), exit(), exit_group(),
getrlimit(), rt_sigreturn(),
sigreturn() system calls and the system calls for querying time and sleeping are
implicitly allow-listed and do not need to be listed explicitly.
The default action when a system call is denied is to terminate the processes with a
C<SIGSYS> signal. This can changed using C<SystemCallErrorNumber>,
see below. In addition, deny-listed system calls and system call groups may optionally be suffixed
with a colon (C<:>) and an argument in the same format as
C<SystemCallErrorNumber>, to take this action when the matching system call is made.
This takes precedence over the action specified in C<SystemCallErrorNumber>.
This feature makes use of the Secure Computing Mode 2 interfaces of the kernel ('seccomp
filtering') and is useful for enforcing a minimal sandboxing environment.
Note that on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn
off alternative ABIs for services, so that they cannot be used to circumvent the restrictions of this
option. Specifically, it is recommended to combine this option with
C<SystemCallArchitectures=native> or similar.
Note that strict system call filters may impact execution and error handling code paths of the
service invocation. Specifically, access to the execve() system call is required
for the execution of the service binary \x{2014} if it is blocked service invocation will necessarily fail.
Also, if execution of the service binary fails for some reason (for example: missing service
executable), the error handling logic might require access to an additional set of system calls in
order to process and log this failure correctly. It might be necessary to temporarily disable system
call filters in order to allow debugging of such failures.
If you specify both types of this option (i.e. allow-listing and deny-listing), the first
encountered will take precedence and will dictate the default action (termination or approval of a
system call). Then the next occurrences of this option will add or delete the listed system calls
from the set of the filtered system calls, depending of its type and the default action. (For
example, if you have started with an allow list rule for read() and
write(), and right after it add a deny list rule for write(),
then write() will be removed from the set.)
As the number of possible system calls is large, predefined groups of system calls are
provided. A group starts with C<\@> character, followed by name of the set.
Currently predefined system call setsSetDescription\@aioAsynchronous I/O (L<io_setup(2)>, L<io_submit(2)>, and related
calls)\@basic-ioSystem calls for basic I/O: reading, writing, seeking, file descriptor duplication and closing
(L<read(2)>, L<write(2)>, and related calls)\@chownChanging file ownership (L<chown(2)>, L<fchownat(2)>, and related
calls)\@clockSystem calls for changing the system clock (L<adjtimex(2)>, L<settimeofday(2)>, and related
calls)\@cpu-emulationSystem calls for CPU emulation functionality (L<vm86(2)> and related calls)\@debugDebugging,
performance monitoring and tracing functionality (L<ptrace(2)>, L<perf_event_open(2)> and related
calls)\@file-systemFile system operations: opening, creating files and directories for read and write, renaming and
removing them, reading file properties, or creating hard and symbolic links\@io-eventEvent loop system calls
(L<poll(2)>, L<select(2)>, L<epoll(7)>, L<eventfd(2)> and related calls)\@ipcPipes, SysV IPC, POSIX Message Queues and
other IPC (L<mq_overview(7)>, L<svipc(7)>)\@keyringKernel keyring access (L<keyctl(2)> and related calls)\@memlockLocking
of memory in RAM (L<mlock(2)>, L<mlockall(2)> and related calls)\@moduleLoading and unloading of kernel modules
(L<init_module(2)>, L<delete_module(2)> and related calls)\@mountMounting and unmounting of file systems (L<mount(2)>,
L<chroot(2)>, and related calls)\@network-ioSocket I/O (including local AF_UNIX): L<socket(7)>,
L<unix(7)>\@obsoleteUnusual, obsolete or unimplemented (L<create_module(2)>, L<gtty(2)>, \x{2026})\@pkeySystem calls that deal
with memory protection keys (L<pkeys(7)>)\@privilegedAll system calls which need super-user capabilities
(L<capabilities(7)>)\@processProcess control, execution, namespacing operations (L<clone(2)>, L<kill(2)>,
L<namespaces(7)>, \x{2026})\@raw-ioRaw I/O port access (L<ioperm(2)>, L<iopl(2)>, pciconfig_read(), \x{2026})\@rebootSystem calls for
rebooting and reboot preparation (L<reboot(2)>, kexec(), \x{2026})\@resourcesSystem calls for changing resource limits, memory
and scheduling parameters (L<setrlimit(2)>, L<setpriority(2)>, \x{2026})\@sandboxSystem calls for sandboxing programs
(L<seccomp(2)>, Landlock system calls, \x{2026})\@setuidSystem calls for changing user ID and group ID credentials,
(L<setuid(2)>, L<setgid(2)>, L<setresuid(2)>, \x{2026})\@signalSystem calls for manipulating and handling process signals
(L<signal(2)>, L<sigprocmask(2)>, \x{2026})\@swapSystem calls for enabling/disabling swap devices (L<swapon(2)>,
L<swapoff(2)>)\@syncSynchronizing files and memory to disk (L<fsync(2)>, L<msync(2)>, and related calls)\@system-serviceA
reasonable set of system calls used by common system services, excluding any special purpose calls. This is the
recommended starting point for allow-listing system calls for system services, as it contains what is typically needed
by system services, but excludes overly specific interfaces. For example, the following APIs are excluded: C<\@clock>,
C<\@mount>, C<\@swap>, C<\@reboot>.\@timerSystem calls for scheduling operations by time (L<alarm(2)>, L<timer_create(2)>,
\x{2026})\@knownAll system calls defined by the kernel. This list is defined statically in systemd based on a kernel version
that was available when this systemd version was released. It will become progressively more out-of-date as the kernel
is updated.
Note, that as new system calls are added to the kernel, additional system calls might be added to the groups
above. Contents of the sets may also change between systemd versions. In addition, the list of system calls
depends on the kernel version and architecture for which systemd was compiled. Use
systemd-analyze\x{a0}syscall-filter to list the actual list of system calls in each
filter.
Generally, allow-listing system calls (rather than deny-listing) is the safer mode of
operation. It is recommended to enforce system call allow lists for all long-running system
services. Specifically, the following lines are a relatively safe basic choice for the majority of
system services:
[Service]
SystemCallFilter=\@system-service
SystemCallErrorNumber=EPERM
Note that various kernel system calls are defined redundantly: there are multiple system calls
for executing the same operation. For example, the pidfd_send_signal() system
call may be used to execute operations similar to what can be done with the older
kill() system call, hence blocking the latter without the former only provides
weak protection. Since new system calls are added regularly to the kernel as development progresses,
keeping system call deny lists comprehensive requires constant work. It is thus recommended to use
allow-listing instead, which offers the benefit that new system calls are by default implicitly
blocked until the allow list is updated.
Also note that a number of system calls are required to be accessible for the dynamic linker to
work. The dynamic linker is required for running most regular programs (specifically: all dynamic ELF
binaries, which is how most distributions build packaged programs). This means that blocking these
system calls (which include open(), openat() or
mmap()) will make most programs typically shipped with generic distributions
unusable.
It is recommended to combine the file system namespacing related options with
C<SystemCallFilter=~\@mount>, in order to prohibit the unit's processes to undo the
mappings. Specifically these are the options C<PrivateTmp>,
C<PrivateDevices>, C<ProtectSystem>, C<ProtectHome>,
C<ProtectKernelTunables>, C<ProtectControlGroups>,
C<ProtectKernelLogs>, C<ProtectClock>, C<ReadOnlyPaths>,
C<InaccessiblePaths> and C<ReadWritePaths>.",
'type' => 'list'
},
'SystemCallErrorNumber',
{
'description' => 'Takes an C<errno> error number (between 1 and 4095) or errno name
such as C<EPERM>, C<EACCES> or C<EUCLEAN>, to
return when the system call filter configured with C<SystemCallFilter> is triggered,
instead of terminating the process immediately. See L<errno(3)> for a
full list of error codes. When this setting is not used, or when the empty string or the special
setting C<kill> is assigned, the process will be terminated immediately when the
filter is triggered.',
'type' => 'leaf',
'value_type' => 'uniline'
lib/Config/Model/models/Systemd/Common/Exec.pl view on Meta::CPAN
details.",
'type' => 'leaf',
'value_type' => 'uniline'
},
'SystemCallLog',
{
'cargo' => {
'type' => 'leaf',
'value_type' => 'uniline'
},
'description' => 'Takes a space-separated list of system call names. If this setting is used, all
system calls executed by the unit processes for the listed ones will be logged. If the first
character of the list is C<~>, the effect is inverted: all system calls except the
listed system calls will be logged. This feature makes use of the Secure Computing Mode 2 interfaces
of the kernel (\'seccomp filtering\') and is useful for auditing or setting up a minimal sandboxing
environment. This option may be specified more than once, in which case the filter masks are merged.
If the empty string is assigned, the filter is reset, all prior assignments will have no effect.
This does not affect commands prefixed with C<+>.',
'type' => 'list'
},
'Environment',
{
'cargo' => {
'type' => 'leaf',
'value_type' => 'uniline'
},
'description' => "Sets environment variables for executed processes. Each line is unquoted using the
rules described in \"Quoting\" section in
L<systemd.syntax(7)>
and becomes a list of variable assignments. If you need to assign a value containing spaces or the
equals sign to a variable, put quotes around the whole assignment. Variable expansion is not
performed inside the strings and the C<\$> character has no special meaning. Specifier
expansion is performed, see the \"Specifiers\" section in
L<systemd.unit(5)>.
This option may be specified more than once, in which case all listed variables will be set. If
the same variable is listed twice, the later setting will override the earlier setting. If the empty
string is assigned to this option, the list of environment variables is reset, all prior assignments
have no effect.
The names of the variables can contain ASCII letters, digits, and the underscore character.
Variable names cannot be empty or start with a digit. In variable values, most characters are
allowed, but non-printable characters are currently rejected.
Example:
Environment=\"VAR1=word1 word2\" VAR2=word3 \"VAR3=\$word 5 6\"
gives three variables C<VAR1>,
C<VAR2>, C<VAR3>
with the values C<word1 word2>,
C<word3>, C<\$word 5 6>.
See L<environ(7)> for
details about environment variables.
Note that environment variables are not suitable for passing secrets (such as passwords, key
material, \x{2026}) to service processes. Environment variables set for a unit are exposed to unprivileged
clients via D-Bus IPC, and generally not understood as being data that requires protection. Moreover,
environment variables are propagated down the process tree, including across security boundaries
(such as setuid/setgid executables), and hence might leak to processes that should not have access to
the secret data. Use C<LoadCredential>, C<LoadCredentialEncrypted>
or C<SetCredentialEncrypted> (see below) to pass data to unit processes
securely.",
'type' => 'list'
},
'EnvironmentFile',
{
'cargo' => {
'type' => 'leaf',
'value_type' => 'uniline'
},
'description' => 'Similar to C<Environment>, but reads the environment variables from
a text file. The text file should contain newline-separated variable assignments. Empty lines, lines
without an C<=> separator, or lines starting with C<;> or
C<#> will be ignored, which may be used for commenting. The file must be encoded with
UTF-8. Valid characters are
L<unicode scalar values|https://www.unicode.org/glossary/#unicode_scalar_value>
other than
L<unicode noncharacters|https://www.unicode.org/glossary/#noncharacter>,
C<U+0000> C<NUL>, and C<U+FEFF>L<unicode byte order mark|https://www.unicode.org/glossary/#byte_order_mark>.
Control codes other than C<NUL> are allowed.
In the file, an unquoted value after the C<=> is parsed with the same backslash-escape
rules as L<POSIX shell unquoted
text|https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_01>, but unlike in a shell,
interior whitespace is preserved and quotes after the
first non-whitespace character are preserved. Leading and trailing whitespace (space, tab, carriage return) is
discarded, but interior whitespace within the line is preserved verbatim. A line ending with a backslash will be
continued to the following one, with the newline itself discarded. A backslash
C<\\> followed by any character other than newline will preserve the following character, so that
C<\\\\> will become the value C<\\>.
In the file, a C<\'>-quoted value after the C<=> can span
multiple lines and contain any character verbatim other than single quote, like L<POSIX
shell single-quoted text|https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_02>. No
backslash-escape sequences are recognized. Leading and trailing
whitespace outside of the single quotes is discarded.
In the file, a C<">-quoted value after the C<=> can span
multiple lines, and the same escape sequences are recognized as in L<POSIX
shell double-quoted text|https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_03>.
Backslash (C<\\>) followed by any of
C<"\\`$> will preserve that character. A backslash followed by newline is a line
continuation, and the newline itself is discarded. A backslash followed by any other character is
ignored; both the backslash and the following character are preserved verbatim. Leading and trailing
whitespace outside of the double quotes is discarded.
The argument passed should be an absolute filename or wildcard expression. If the file does not
exist, cannot be read, or contains invalid content, the service will fail to start. To make the file
optional, prefix the path with C<->, which causes all errors related to the file to be
silently ignored. This option may be specified more than once in which case all specified files are read.
If the empty string is assigned to this option, the list of files to read is reset, all prior assignments
have no effect.
The files listed with this directive will be read shortly before the process is executed (more
specifically, after all processes from a previous unit state terminated. This means you can generate these
files in one unit state, and read it with this option in the next. The files are read from the file
system of the service manager, before any file system changes like bind mounts take place).
Settings from these files override settings made with C<Environment>. If the same
( run in 1.798 second using v1.01-cache-2.11-cpan-5735350b133 )