view release on metacpan or  search on metacpan

lib/Config/Model/models/Systemd/Common/Exec.pl  view on Meta::CPAN

in the above two cases, a missing credential is not considered fatal.

If an absolute path referring to a directory is specified, every file in that directory
(recursively) will be loaded as a separate credential. The ID for each credential will be the
provided ID suffixed with C<_\$FILENAME> (e.g., C<Key_file1>). When
loading from a directory, symlinks will be ignored.

The contents of the file/socket may be arbitrary binary or textual data, including newline
characters and C<NUL> bytes.

The C<LoadCredentialEncrypted> setting is identical to
C<LoadCredential>, except that the credential data is decrypted and authenticated
before being passed on to the executed processes. Specifically, the referenced path should refer to a
file or socket with an encrypted credential, as implemented by
L<systemd-creds(1)>. This
credential is loaded, decrypted, authenticated and then passed to the application in plaintext form,
in the same way a regular credential specified via C<LoadCredential> would be. A
credential configured this way may be symmetrically encrypted/authenticated with a secret key derived
from the system's TPM2 security chip, or with a secret key stored in
C</var/lib/systemd/credential.secret>, or with both. Using encrypted and
authenticated credentials improves security as credentials are not stored in plaintext and only
authenticated and decrypted into plaintext the moment a service requiring them is started. Moreover,
credentials may be bound to the local hardware and installations, so that they cannot easily be
analyzed offline, or be generated externally. See
L<systemd.resource-control(5)>
for the details about C<DevicePolicy> or C<DeviceAllow>.

Note that encrypted credentials targeted for services of the per-user service manager must be
encrypted with systemd-creds encrypt --user, and those for the system service
manager without the C<--user> switch. Encrypted credentials are always targeted to a
specific user or the system as a whole, and it is ensured that per-user service managers cannot
decrypt secrets intended for the system or for other users.

The credential files/IPC sockets must be accessible to the service manager, but do not have to
be directly accessible to the unit's processes: the credential data is read and copied into separate,
read-only copies for the unit that are accessible to appropriately privileged processes. This is
particularly useful in combination with C<DynamicUser> as this way privileged data
can be made available to processes running under a dynamic UID (i.e. not a previously known one)
without having to open up access to all users.

In order to reference the path a credential may be read from within a
C<ExecStart> command line use C<\${CREDENTIALS_DIRECTORY}/mycred>,
e.g. C<ExecStart=cat \${CREDENTIALS_DIRECTORY}/mycred>. In order to reference the path
a credential may be read from within a C<Environment> line use
C<%d/mycred>, e.g. C<Environment=MYCREDPATH=%d/mycred>. For system
services the path may also be referenced as
C</run/credentials/UNITNAME> in cases where no
interpolation is possible, e.g. configuration files of software that does not yet support credentials
natively. C<\$CREDENTIALS_DIRECTORY> is considered the primary interface to look for
credentials, though, since it also works for user services.

Currently, an accumulated credential size limit of 1 MB per unit is enforced.

The service manager itself may receive system credentials that can be propagated to services
from a hosting container manager or VM hypervisor. See the L<Container
Interface|https://systemd.io/CONTAINER_INTERFACE> documentation for details
about the former. For the latter, pass L<DMI/SMBIOS|https://www.dmtf.org/standards/smbios> OEM string table entries
(field type
11) with a prefix of C<io.systemd.credential:> or
C<io.systemd.credential.binary:>. In both cases a key/value pair separated by
C<=> is expected. In the latter case, the right-hand side is Base64 decoded when
parsed (thus permitting binary data to be passed in). Example
L<qemu|https://www.qemu.org/docs/master/system/index.html> switch: C<-smbios
type=11,value=io.systemd.credential:xx=yy>, or C<-smbios
type=11,value=io.systemd.credential.binary:rick=TmV2ZXIgR29ubmEgR2l2ZSBZb3UgVXA=>. Alternatively,
use the qemu C<fw_cfg> node
C<opt/io.systemd.credentials/>. Example qemu switch:
C<-fw_cfg name=opt/io.systemd.credentials/mycred,string=supersecret>. They may also
be passed from the UEFI firmware environment via
L<systemd-stub(7)>,
from the initrd (see
L<systemd(1)>), or be
specified on the kernel command line using the C<systemd.set_credential=> and
C<systemd.set_credential_binary=> switches (see
L<systemd(1)> \x{2013} this is
not recommended since unprivileged userspace can read the kernel command line).

If referencing an C<AF_UNIX> stream socket to connect to, the connection will
originate from an abstract namespace socket, that includes information about the unit and the
credential ID in its socket name. Use L<getpeername(2)>
to query this information. The returned socket name is formatted as C<NUL>RANDOM C</unit/> UNITC</> ID, i.e. a C<NUL>
byte (as required
for abstract namespace socket names), followed by a random string (consisting of alphadecimal
characters), followed by the literal string C</unit/>, followed by the requesting
unit name, followed by the literal character C</>, followed by the textual credential
ID requested. Example: C<\\0adf9d86b6eda275e/unit/foobar.service/credx> in case the
credential C<credx> is requested for a unit C<foobar.service>. This
functionality is useful for using a single listening socket to serve credentials to multiple
consumers.

For further information see L<System and Service
Credentials|https://systemd.io/CREDENTIALS> documentation.",
        'type' => 'leaf',
        'value_type' => 'uniline'
      },
      'LoadCredentialEncrypted',
      {
        'description' => "Pass a credential to the unit. Credentials are limited-size binary or textual objects
that may be passed to unit processes. They are primarily intended for passing cryptographic keys
(both public and private) or certificates, user account information or identity information from host
to services, but can be freely used to pass any kind of limited-size information to a service. The
data is accessible from the unit's processes via the file system, at a read-only location that (if
possible and permitted) is backed by non-swappable memory. The data is only accessible to the user
associated with the unit, via the C<User>/C<DynamicUser> settings
(as well as the superuser). When available, the location of credentials is exported as the
C<\$CREDENTIALS_DIRECTORY> environment variable to the unit's processes.

The C<LoadCredential> setting takes a textual ID to use as name for a
credential plus a file system path, separated by a colon. The ID must be a short ASCII string
suitable as filename in the filesystem, and may be chosen freely by the user. If the specified path
is absolute it is opened as regular file and the credential data is read from it. If the absolute
path refers to an C<AF_UNIX> stream socket in the file system a connection is made
to it (once at process invocation) and the credential data read from the connection, providing an
easy IPC integration point for dynamically transferring credentials from other services.

If the specified path is not absolute and itself qualifies as valid credential identifier it is
attempted to find a credential that the service manager itself received under the specified name \x{2014}
which may be used to propagate credentials from an invoking environment (e.g. a container manager
that invoked the service manager) into a service. If no matching passed credential is found, the
system service manager will search the directories C</etc/credstore/>,
C</run/credstore/> and C</usr/lib/credstore/> for files under the

lib/Config/Model/models/Systemd/Common/Exec.pl  view on Meta::CPAN

in the above two cases, a missing credential is not considered fatal.

If an absolute path referring to a directory is specified, every file in that directory
(recursively) will be loaded as a separate credential. The ID for each credential will be the
provided ID suffixed with C<_\$FILENAME> (e.g., C<Key_file1>). When
loading from a directory, symlinks will be ignored.

The contents of the file/socket may be arbitrary binary or textual data, including newline
characters and C<NUL> bytes.

The C<LoadCredentialEncrypted> setting is identical to
C<LoadCredential>, except that the credential data is decrypted and authenticated
before being passed on to the executed processes. Specifically, the referenced path should refer to a
file or socket with an encrypted credential, as implemented by
L<systemd-creds(1)>. This
credential is loaded, decrypted, authenticated and then passed to the application in plaintext form,
in the same way a regular credential specified via C<LoadCredential> would be. A
credential configured this way may be symmetrically encrypted/authenticated with a secret key derived
from the system's TPM2 security chip, or with a secret key stored in
C</var/lib/systemd/credential.secret>, or with both. Using encrypted and
authenticated credentials improves security as credentials are not stored in plaintext and only
authenticated and decrypted into plaintext the moment a service requiring them is started. Moreover,
credentials may be bound to the local hardware and installations, so that they cannot easily be
analyzed offline, or be generated externally. See
L<systemd.resource-control(5)>
for the details about C<DevicePolicy> or C<DeviceAllow>.

Note that encrypted credentials targeted for services of the per-user service manager must be
encrypted with systemd-creds encrypt --user, and those for the system service
manager without the C<--user> switch. Encrypted credentials are always targeted to a
specific user or the system as a whole, and it is ensured that per-user service managers cannot
decrypt secrets intended for the system or for other users.

The credential files/IPC sockets must be accessible to the service manager, but do not have to
be directly accessible to the unit's processes: the credential data is read and copied into separate,
read-only copies for the unit that are accessible to appropriately privileged processes. This is
particularly useful in combination with C<DynamicUser> as this way privileged data
can be made available to processes running under a dynamic UID (i.e. not a previously known one)
without having to open up access to all users.

In order to reference the path a credential may be read from within a
C<ExecStart> command line use C<\${CREDENTIALS_DIRECTORY}/mycred>,
e.g. C<ExecStart=cat \${CREDENTIALS_DIRECTORY}/mycred>. In order to reference the path
a credential may be read from within a C<Environment> line use
C<%d/mycred>, e.g. C<Environment=MYCREDPATH=%d/mycred>. For system
services the path may also be referenced as
C</run/credentials/UNITNAME> in cases where no
interpolation is possible, e.g. configuration files of software that does not yet support credentials
natively. C<\$CREDENTIALS_DIRECTORY> is considered the primary interface to look for
credentials, though, since it also works for user services.

Currently, an accumulated credential size limit of 1 MB per unit is enforced.

The service manager itself may receive system credentials that can be propagated to services
from a hosting container manager or VM hypervisor. See the L<Container
Interface|https://systemd.io/CONTAINER_INTERFACE> documentation for details
about the former. For the latter, pass L<DMI/SMBIOS|https://www.dmtf.org/standards/smbios> OEM string table entries
(field type
11) with a prefix of C<io.systemd.credential:> or
C<io.systemd.credential.binary:>. In both cases a key/value pair separated by
C<=> is expected. In the latter case, the right-hand side is Base64 decoded when
parsed (thus permitting binary data to be passed in). Example
L<qemu|https://www.qemu.org/docs/master/system/index.html> switch: C<-smbios
type=11,value=io.systemd.credential:xx=yy>, or C<-smbios
type=11,value=io.systemd.credential.binary:rick=TmV2ZXIgR29ubmEgR2l2ZSBZb3UgVXA=>. Alternatively,
use the qemu C<fw_cfg> node
C<opt/io.systemd.credentials/>. Example qemu switch:
C<-fw_cfg name=opt/io.systemd.credentials/mycred,string=supersecret>. They may also
be passed from the UEFI firmware environment via
L<systemd-stub(7)>,
from the initrd (see
L<systemd(1)>), or be
specified on the kernel command line using the C<systemd.set_credential=> and
C<systemd.set_credential_binary=> switches (see
L<systemd(1)> \x{2013} this is
not recommended since unprivileged userspace can read the kernel command line).

If referencing an C<AF_UNIX> stream socket to connect to, the connection will
originate from an abstract namespace socket, that includes information about the unit and the
credential ID in its socket name. Use L<getpeername(2)>
to query this information. The returned socket name is formatted as C<NUL>RANDOM C</unit/> UNITC</> ID, i.e. a C<NUL>
byte (as required
for abstract namespace socket names), followed by a random string (consisting of alphadecimal
characters), followed by the literal string C</unit/>, followed by the requesting
unit name, followed by the literal character C</>, followed by the textual credential
ID requested. Example: C<\\0adf9d86b6eda275e/unit/foobar.service/credx> in case the
credential C<credx> is requested for a unit C<foobar.service>. This
functionality is useful for using a single listening socket to serve credentials to multiple
consumers.

For further information see L<System and Service
Credentials|https://systemd.io/CREDENTIALS> documentation.",
        'type' => 'leaf',
        'value_type' => 'uniline'
      },
      'ImportCredential',
      {
        'description' => "Pass one or more credentials to the unit. Takes a credential name for which we will
attempt to find a credential that the service manager itself received under the specified name \x{2014}
which may be used to propagate credentials from an invoking environment (e.g. a container manager
that invoked the service manager) into a service. If the credential name is a glob, all credentials
matching the glob are passed to the unit. Matching credentials are searched for in the system
credentials, the encrypted system credentials, and under C</etc/credstore/>,
C</run/credstore/>, C</usr/lib/credstore/>,
C</run/credstore.encrypted/>, C</etc/credstore.encrypted/>, and
C</usr/lib/credstore.encrypted/> in that order. When multiple credentials of the
same name are found, the first one found is used.

The globbing expression implements a restrictive subset of L<glob(7)>: only
a single trailing C<*> wildcard may be specified. Both C<?> and
C<[]> wildcards are not permitted, nor are C<*> wildcards anywhere
except at the end of the glob expression.

Optionally, the credential name or glob may be followed by a colon followed by a rename pattern.
If specified, all credentials matching the credential name or glob are renamed according to the given
pattern. For example, if C<ImportCredential=my.original.cred:my.renamed.cred> is
specified, the service manager will read the C<my.original.cred> credential and make
it available as the C<my.renamed.cred> credential to the service. Similarly, if
C<ImportCredential=my.original.*:my.renamed.> is specified, the service manager will
read all credentials starting with C<my.original.> and make them available as
C<my.renamed.xxx> to the service.