From b750101eb236130cf056c675997decbac904cc49 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 17:35:18 +0200 Subject: Adding upstream version 252.22. Signed-off-by: Daniel Baumann --- man/crypttab.xml | 867 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 867 insertions(+) create mode 100644 man/crypttab.xml (limited to 'man/crypttab.xml') diff --git a/man/crypttab.xml b/man/crypttab.xml new file mode 100644 index 0000000..ef6cd2b --- /dev/null +++ b/man/crypttab.xml @@ -0,0 +1,867 @@ + + + + + + + + crypttab + systemd + + + + crypttab + 5 + + + + crypttab + Configuration for encrypted block devices + + + + /etc/crypttab + + + + Description + + The /etc/crypttab file describes + encrypted block devices that are set up during system boot. + + Empty lines and lines starting with the # + character are ignored. Each of the remaining lines describes one + encrypted block device. Fields are delimited by white space. + + Each line is in the formvolume-name encrypted-device key-file options + The first two fields are mandatory, the remaining two are + optional. + + Setting up encrypted block devices using this file supports four encryption modes: LUKS, TrueCrypt, + BitLocker and plain. See cryptsetup8 for + more information about each mode. When no mode is specified in the options field and the block device + contains a LUKS signature, it is opened as a LUKS device; otherwise, it is assumed to be in raw dm-crypt + (plain mode) format. + + The four fields of /etc/crypttab are defined as follows: + + + + The first field contains the name of the resulting volume with decrypted data; its + block device is set up below /dev/mapper/. + + The second field contains a path to the underlying block + device or file, or a specification of a block device via + UUID= followed by the UUID. + + The third field specifies an absolute path to a file with the encryption + key. Optionally, the path may be followed by : and an + /etc/fstab style device specification (e.g. starting with + LABEL= or similar); in which case the path is taken relative to the specified + device's file system root. If the field is not present or is none or + -, a key file named after the volume to unlock (i.e. the first column of the line), + suffixed with .key is automatically loaded from the + /etc/cryptsetup-keys.d/ and /run/cryptsetup-keys.d/ + directories, if present. Otherwise, the password has to be manually entered during system boot. For + swap encryption, /dev/urandom may be used as key file, resulting in a randomized + key. + + If the specified key file path refers to an AF_UNIX stream socket in the + file system, the key is acquired by connecting to the socket and reading it from the connection. This + allows the implementation of a service to provide key information dynamically, at the moment when it is + needed. For details see below. + + The fourth field, if present, is a comma-delimited list of options. The supported + options are listed below. + + + + + Key Acquisition + + Six different mechanisms for acquiring the decryption key or passphrase unlocking the encrypted + volume are supported. Specifically: + + + + Most prominently, the user may be queried interactively during volume activation + (i.e. typically at boot), asking them to type in the necessary passphrases. + + The (unencrypted) key may be read from a file on disk, possibly on removable media. The third field + of each line encodes the location, for details see above. + + The (unencrypted) key may be requested from another service, by specifying an + AF_UNIX file system socket in place of a key file in the third field. For details + see above and below. + + The key may be acquired via a PKCS#11 compatible hardware security token or + smartcard. In this case an encrypted key is stored on disk/removable media, acquired via + AF_UNIX, or stored in the LUKS2 JSON token metadata header. The encrypted key is + then decrypted by the PKCS#11 token with an RSA key stored on it, and then used to unlock the encrypted + volume. Use the option described below to use this mechanism. + + Similarly, the key may be acquired via a FIDO2 compatible hardware security token + (which must implement the "hmac-secret" extension). In this case a key generated randomly during + enrollment is stored on disk/removable media, acquired via AF_UNIX, or stored in + the LUKS2 JSON token metadata header. The random key is hashed via a keyed hash function (HMAC) on the + FIDO2 token, using a secret key stored on the token that never leaves it. The resulting hash value is + then used as key to unlock the encrypted volume. Use the option + described below to use this mechanism. + + Similarly, the key may be acquired via a TPM2 security chip. In this case a (during + enrollment) randomly generated key — encrypted by an asymmetric key derived from the TPM2 chip's seed + key — is stored on disk/removable media, acquired via AF_UNIX, or stored in the + LUKS2 JSON token metadata header. Use the option described below to use + this mechanism. + + + For the latter five mechanisms the source for the key material used for unlocking the volume is + primarily configured in the third field of each /etc/crypttab line, but may also + configured in /etc/cryptsetup-keys.d/ and + /run/cryptsetup-keys.d/ (see above) or in the LUKS2 JSON token header (in case of + the latter three). Use the + systemd-cryptenroll1 + tool to enroll PKCS#11, FIDO2 and TPM2 devices in LUKS2 volumes. + + + + Supported Options + + The following options may be used in the fourth field of each line: + + + + + + + Specifies the cipher to use. See cryptsetup8 + for possible values and the default value of this option. A cipher with unpredictable IV values, such + as aes-cbc-essiv:sha256, is recommended. Embedded commas in the cipher + specification need to be escaped by preceding them with a backslash, see example below. + + + + + + + Allow discard requests to be passed through the encrypted block + device. This improves performance on SSD storage but has security implications. + + + + + + + Specifies the hash to use for password + hashing. See + cryptsetup8 + for possible values and the default value of this + option. + + + + + + Use a detached (separated) metadata device or + file where the LUKS header is stored. This option is only + relevant for LUKS devices. See + cryptsetup8 + for possible values and the default value of this + option. + + Optionally, the path may be followed by : and an + /etc/fstab device specification (e.g. starting with UUID= or + similar); in which case, the path is relative to the device file system root. The device gets mounted + automatically for LUKS device activation duration only. + + + + + + Specifies the number of bytes to skip at the + start of the key file. See + cryptsetup8 + for possible values and the default value of this + option. + + + + + + Specifies the maximum number of bytes to read + from the key file. See + cryptsetup8 + for possible values and the default value of this option. This + option is ignored in plain encryption mode, as the key file + size is then given by the key size. + + + + + + If enabled, the specified key file is erased after the volume is activated or when + activation fails. This is in particular useful when the key file is only acquired transiently before + activation (e.g. via a file in /run/, generated by a service running before + activation), and shall be removed after use. Defaults to off. + + + + + + Specifies the key slot to compare the + passphrase or key against. If the key slot does not match the + given passphrase or key, but another would, the setup of the + device will fail regardless. This option implies + . See + cryptsetup8 + for possible values. The default is to try all key slots in + sequential order. + + + + + + Specifies the timeout for the device on + which the key file resides or the device used as the key file, + and falls back to a password if it could not be accessed. See + systemd-cryptsetup-generator8 + for key files on external devices. + + + + + + + Force LUKS mode. When this mode is used, the + following options are ignored since they are provided by the + LUKS header on the device: , + , + . + + + + + + Decrypt BitLocker drive. Encryption parameters + are deduced by cryptsetup from BitLocker header. + + + + + + Marks this cryptsetup device as requiring network. It will be + started after the network is available, similarly to + systemd.mount5 + units marked with . The service unit to set up this device + will be ordered between remote-fs-pre.target and + remote-cryptsetup.target, instead of + cryptsetup-pre.target and + cryptsetup.target. + + Hint: if this device is used for a mount point that is specified in + fstab5, + the option should also be used for the mount + point. Otherwise, a dependency loop might be created where the mount point + will be pulled in by local-fs.target, while the + service to configure the network is usually only started after + the local file system has been mounted. + + + + + + + This device will not be added to cryptsetup.target. + This means that it will not be automatically unlocked on boot, unless something else pulls + it in. In particular, if the device is used for a mount point, it'll be unlocked + automatically during boot, unless the mount point itself is also disabled with + . + + + + + + This device will not be a hard dependency of + cryptsetup.target. It'll still be pulled in and started, but the system + will not wait for the device to show up and be unlocked, and boot will not fail if this is + unsuccessful. Note that other units that depend on the unlocked device may still fail. In + particular, if the device is used for a mount point, the mount point itself also needs to + have the option, or the boot will fail if the device is not unlocked + successfully. + + + + + + Start offset in the backend device, in 512-byte sectors. This + option is only relevant for plain devices. + + + + + + Force plain encryption mode. + + + + + + Set up the encrypted block device in read-only + mode. + + + + + + Perform encryption using the same CPU that IO was submitted on. The default is to use + an unbound workqueue so that encryption work is automatically balanced between available CPUs. + + This requires kernel 4.0 or newer. + + + + + + + Disable offloading writes to a separate thread after encryption. There are some + situations where offloading write requests from the encryption threads to a dedicated thread degrades + performance significantly. The default is to offload write requests to a dedicated thread because it + benefits the CFQ scheduler to have writes submitted using the same context. + + This requires kernel 4.0 or newer. + + + + + + + Bypass dm-crypt internal workqueue and process read requests synchronously. The + default is to queue these requests and process them asynchronously. + + This requires kernel 5.9 or newer. + + + + + + Bypass dm-crypt internal workqueue and process write requests synchronously. The + default is to queue these requests and process them asynchronously. + + This requires kernel 5.9 or newer. + + + + + + + How many 512-byte sectors of the encrypted data to skip at the + beginning. This is different from the option with respect + to the sector numbers used in initialization vector (IV) calculation. Using + will shift the IV calculation by the same negative + amount. Hence, if is given, + sector n will get a sector number of 0 for the IV + calculation. Using causes sector + n to also be the first sector of the mapped device, but + with its number for IV generation being n. + + This option is only relevant for plain devices. + + + + + + + Specifies the key size in bits. See + cryptsetup8 + for possible values and the default value of this + option. + + + + + + Specifies the sector size in bytes. See + cryptsetup8 + for possible values and the default value of this + option. + + + + + + The encrypted block device will be used as a + swap device, and will be formatted accordingly after setting + up the encrypted block device, with + mkswap8. + This option implies . + + WARNING: Using the option will + destroy the contents of the named partition during every boot, + so make sure the underlying block device is specified + correctly. + + + + + + Use TrueCrypt encryption mode. When this mode + is used, the following options are ignored since they are + provided by the TrueCrypt header on the device or do not + apply: + , + , + , + , + . + + When this mode is used, the passphrase is read from the + key file given in the third field. Only the first line of this + file is read, excluding the new line character. + + Note that the TrueCrypt format uses both passphrase and + key files to derive a password for the volume. Therefore, the + passphrase and all key files need to be provided. Use + to provide the absolute path + to all key files. When using an empty passphrase in + combination with one or more key files, use + /dev/null as the password file in the third + field. + + + + + + Use the hidden TrueCrypt volume. This option + implies . + + This will map the hidden volume that is inside of the + volume provided in the second field. Please note that there is + no protection for the hidden volume if the outer volume is + mounted instead. See + cryptsetup8 + for more information on this limitation. + + + + + + Specifies the absolute path to a key file to + use for a TrueCrypt volume. This implies + and can be used more than once to + provide several key files. + + See the entry for on the + behavior of the passphrase and key files when using TrueCrypt + encryption mode. + + + + + + Use TrueCrypt in system encryption mode. This + option implies . + + + + + + Check for a VeraCrypt volume. VeraCrypt is a fork of + TrueCrypt that is mostly compatible, but uses different, stronger key + derivation algorithms that cannot be detected without this flag. + Enabling this option could substantially slow down unlocking, because + VeraCrypt's key derivation takes much longer than TrueCrypt's. This + option implies . + + + + + + Specifies the timeout for querying for a + password. If no unit is specified, seconds is used. Supported + units are s, ms, us, min, h, d. A timeout of 0 waits + indefinitely (which is the default). + + + + + + The encrypted block device will be prepared for using it as + /tmp/; it will be formatted using mkfs8. Takes + a file system type as argument, such as ext4, xfs or + btrfs. If no argument is specified defaults to ext4. This + option implies . + + WARNING: Using the option will destroy the contents of the named partition + during every boot, so make sure the underlying block device is specified correctly. + + + + + + Specifies the maximum number of times the user + is queried for a password. The default is 3. If set to 0, the + user is queried for a password indefinitely. + + + + + + Takes a boolean argument, defaults to false. If true, never query interactively + for the password/PIN. Useful for headless systems. + + + + + + If the encryption password is read from console, it has to be entered twice to + prevent typos. + + + + + + Controls whether to echo passwords or security token PINs + that are read from console. Takes a boolean or the special string masked. + The default is . + + If enabled, the typed characters are echoed literally. If disabled, + the typed characters are not echoed in any form, the user will not get + feedback on their input. If set to masked, an asterisk + (*) is echoed for each character typed. Regardless of + which mode is chosen, if the user hits the tabulator key (↹) + at any time, or the backspace key (⌫) before any other + data has been entered, then echo is turned off. + + + + + + Takes either the special value auto or an RFC7512 PKCS#11 URI pointing to a private RSA key + which is used to decrypt the encrypted key specified in the third column of the line. This is useful + for unlocking encrypted volumes through PKCS#11 compatible security tokens or smartcards. See below + for an example how to set up this mechanism for unlocking a LUKS2 volume with a YubiKey security + token. + + If specified as auto the volume must be of type LUKS2 and must carry PKCS#11 + security token metadata in its LUKS2 JSON token section. In this mode the URI and the encrypted key + are automatically read from the LUKS2 JSON token header. Use + systemd-cryptenroll1 + as simple tool for enrolling PKCS#11 security tokens or smartcards in a way compatible with + auto. In this mode the third column of the line should remain empty (that is, + specified as -). + + The specified URI can refer directly to a private RSA key stored on a token or alternatively + just to a slot or token, in which case a search for a suitable private RSA key will be performed. In + this case if multiple suitable objects are found the token is refused. The encrypted key configured + in the third column of the line is passed as is (i.e. in binary form, unprocessed) to RSA + decryption. The resulting decrypted key is then Base64 encoded before it is used to unlock the LUKS + volume. + + Use systemd-cryptenroll --pkcs11-token-uri=list to list all suitable PKCS#11 + security tokens currently plugged in, along with their URIs. + + Note that many newer security tokens that may be used as PKCS#11 security token typically also + implement the newer and simpler FIDO2 standard. Consider using + (described below) to enroll it via FIDO2 instead. Note that a security token enrolled via PKCS#11 + cannot be used to unlock the volume via FIDO2, unless also enrolled via FIDO2, and vice + versa. + + + + + + Takes either the special value auto or the path to a + hidraw device node (e.g. /dev/hidraw1) referring to a FIDO2 + security token that implements the hmac-secret extension (most current hardware + security tokens do). See below for an example how to set up this mechanism for unlocking an encrypted + volume with a FIDO2 security token. + + If specified as auto the FIDO2 token device is automatically discovered, as + it is plugged in. + + FIDO2 volume unlocking requires a client ID hash (CID) to be configured via + (see below) and a key to pass to the security token's HMAC functionality + (configured in the line's third column) to operate. If not configured and the volume is of type + LUKS2, the CID and the key are read from LUKS2 JSON token metadata instead. Use + systemd-cryptenroll1 + as simple tool for enrolling FIDO2 security tokens, compatible with this automatic mode, which is + only available for LUKS2 volumes. + + Use systemd-cryptenroll --fido2-device=list to list all suitable FIDO2 + security tokens currently plugged in, along with their device nodes. + + This option implements the following mechanism: the configured key is hashed via they HMAC + keyed hash function the FIDO2 device implements, keyed by a secret key embedded on the device. The + resulting hash value is Base64 encoded and used to unlock the LUKS2 volume. As it should not be + possible to extract the secret from the hardware token, it should not be possible to retrieve the + hashed key given the configured key — without possessing the hardware token. + + Note that many security tokens that implement FIDO2 also implement PKCS#11, suitable for + unlocking volumes via the option described above. Typically the newer, + simpler FIDO2 standard is preferable. + + + + + + Takes a Base64 encoded FIDO2 client ID to use for the FIDO2 unlock operation. If + specified, but is not, is + implied. If is used but is not, the volume + must be of LUKS2 type, and the CID is read from the LUKS2 JSON token header. Use + systemd-cryptenroll1 + for enrolling a FIDO2 token in the LUKS2 header compatible with this automatic + mode. + + + + + + Takes a string, configuring the FIDO2 Relying Party (rp) for the FIDO2 unlock + operation. If not specified io.systemd.cryptsetup is used, except if the LUKS2 + JSON token header contains a different value. It should normally not be necessary to override + this. + + + + + + Takes either the special value auto or the path to a device node + (e.g. /dev/tpmrm0) referring to a TPM2 security chip. See below for an example + how to set up this mechanism for unlocking an encrypted volume with a TPM2 chip. + + Use (see below) to configure the set of TPM2 PCRs to bind the + volume unlocking to. Use + systemd-cryptenroll1 + as simple tool for enrolling TPM2 security chips in LUKS2 volumes. + + If specified as auto the TPM2 device is automatically discovered. Use + systemd-cryptenroll --tpm2-device=list to list all suitable TPM2 devices currently + available, along with their device nodes. + + This option implements the following mechanism: when enrolling a TPM2 device via + systemd-cryptenroll on a LUKS2 volume, a randomized key unlocking the volume is + generated on the host and loaded into the TPM2 chip where it is encrypted with an asymmetric + "primary" key pair derived from the TPM2's internal "seed" key. Neither the seed key nor the primary + key are permitted to ever leave the TPM2 chip — however, the now encrypted randomized key may. It is + saved in the LUKS2 volume JSON token header. When unlocking the encrypted volume, the primary key + pair is generated on the TPM2 chip again (which works as long as the chip's seed key is correctly + maintained by the TPM2 chip), which is then used to decrypt (on the TPM2 chip) the encrypted key from + the LUKS2 volume JSON token header saved there during enrollment. The resulting decrypted key is then + used to unlock the volume. When the randomized key is encrypted the current values of the selected + PCRs (see below) are included in the operation, so that different PCR state results in different + encrypted keys and the decrypted key can only be recovered if the same PCR state is + reproduced. + + + + + + Takes a + separated list of numeric TPM2 PCR (i.e. "Platform + Configuration Register") indexes to bind the TPM2 volume unlocking to. This option is only useful + when TPM2 enrollment metadata is not available in the LUKS2 JSON token header already, the way + systemd-cryptenroll writes it there. If not used (and no metadata in the LUKS2 + JSON token header defines it), defaults to a list of a single entry: PCR 7. Assign an empty string to + encode a policy that binds the key to no PCRs, making the key accessible to local programs regardless + of the current PCR state. + + + + + + Takes a boolean argument, defaults to false. Controls whether + TPM2 volume unlocking is bound to a PIN in addition to PCRs. Similarly, this option is only useful + when TPM2 enrollment metadata is not available. + + + + + + Takes an absolute path to a TPM2 PCR JSON signature file, as produced by the + systemd-measure1 + tool. This permits locking LUKS2 volumes to any PCR values for which a valid signature matching a + public key specified at key enrollment time can be provided. See + systemd-cryptenroll1 + for details on enrolling TPM2 PCR public keys. If this option is not specified but it is attempted to + unlock a LUKS2 volume with a signed TPM2 PCR enrollment a suitable signature file + tpm2-pcr-signature.json is searched for in /etc/systemd/, + /run/systemd/, /usr/lib/systemd/ (in this + order). + + + + + + Specifies how long to wait at most for configured security devices (i.e. FIDO2, + PKCS#11, TPM2) to show up. Takes a time value in seconds (but other time units may be specified too, + see systemd.time7 + for supported formats). Defaults to 30s. Once the specified timeout elapsed authentication via + password is attempted. Note that this timeout applies to waiting for the security device to show up — + it does not apply to the PIN prompt for the device (should one be needed) or similar. Pass 0 to turn + off the time-out and wait forever. + + + + + + Takes a boolean argument. If enabled, right before asking the user for a password it + is first attempted to unlock the volume with an empty password. This is useful for systems that are + initialized with an encrypted volume with only an empty password set, which shall be replaced with a + suitable password during first boot, but after activation. + + + + + + Specifies how long systemd should wait for a block device to show up before + giving up on the entry. The argument is a time in seconds or explicitly specified units of + s, min, h, ms. + + + + + + + Setup this encrypted block device in the initrd, similarly to + systemd.mount5 + units marked with . + + Although it's not necessary to mark the mount entry for the root file system with + , is still recommended with + the encrypted block device containing the root file system as otherwise systemd will + attempt to detach the device during the regular system shutdown while it's still in + use. With this option the device will still be detached but later after the root file + system is unmounted. + + All other encrypted block devices that contain file systems mounted in the initrd should use + this option. + + + + + + At early boot and when the system manager configuration is + reloaded, this file is translated into native systemd units by + systemd-cryptsetup-generator8. + + + + <constant>AF_UNIX</constant> Key Files + + If the key file path (as specified in the third column of /etc/crypttab + entries, see above) refers to an AF_UNIX stream socket in the file system, the key + is acquired by connecting to the socket and reading the key from the connection. The connection is made + from an AF_UNIX socket name in the abstract namespace, see unix7 for + details. The source socket name is chosen according the following format: + + NUL RANDOM /cryptsetup/ VOLUME + + In other words: a NUL byte (as required for abstract namespace sockets), + followed by a random string (consisting of alphanumeric characters only), followed by the literal + string /cryptsetup/, followed by the name of the volume to acquire they key + for. For example, for the volume myvol: + + \0d7067f78d9827418/cryptsetup/myvol + + Services listening on the AF_UNIX stream socket may query the source socket + name with getpeername2, + and use this to determine which key to send, allowing a single listening socket to serve keys for + multiple volumes. If the PKCS#11 logic is used (see above), the socket source name is picked in similar + fashion, except that the literal string /cryptsetup-pkcs11/ is used. And similarly for + FIDO2 (/cryptsetup-fido2/) and TPM2 (/cryptsetup-tpm2/). A diffent + path component is used so that services providing key material know that the secret key was not requested + directly, but instead an encrypted key that will be decrypted via the PKCS#11/FIDO2/TPM2 logic to acquire + the final secret key. + + + + Examples + + /etc/crypttab example + Set up four encrypted block devices. One using LUKS for normal storage, another one for usage as + a swap device and two TrueCrypt volumes. For the fourth device, the option string is interpreted as two + options cipher=xchacha12,aes-adiantum-plain64, + keyfile-timeout=10s. + + luks UUID=2505567a-9e27-4efe-a4d5-15ad146c258b +swap /dev/sda7 /dev/urandom swap +truecrypt /dev/sda2 /etc/container_password tcrypt +hidden /mnt/tc_hidden /dev/null tcrypt-hidden,tcrypt-keyfile=/etc/keyfile +external /dev/sda3 keyfile:LABEL=keydev keyfile-timeout=10s,cipher=xchacha12\,aes-adiantum-plain64 + + + + + Yubikey-based PKCS#11 Volume Unlocking Example + + The PKCS#11 logic allows hooking up any compatible security token that is capable of storing RSA + decryption keys for unlocking an encrypted volume. Here's an example how to set up a Yubikey security + token for this purpose on a LUKS2 volume, using ykmap1 from the + yubikey-manager project to initialize the token and + systemd-cryptenroll1 + to add it in the LUKS2 volume: + + + + A few notes on the above: + + + We use RSA2048, which is the longest key size current Yubikeys support + We use Yubikey key slot 9d, since that's apparently the keyslot to use for decryption purposes, + see + documentation. + + + + + FIDO2 Volume Unlocking Example + + The FIDO2 logic allows using any compatible FIDO2 security token that implements the + hmac-secret extension for unlocking an encrypted volume. Here's an example how to + set up a FIDO2 security token for this purpose for a LUKS2 volume, using + systemd-cryptenroll1: + + + + + + TPM2 Volume Unlocking Example + + The TPM2 logic allows using any TPM2 chip supported by the Linux kernel for unlocking an + encrypted volume. Here's an example how to set up a TPM2 chip for this purpose for a LUKS2 volume, + using + systemd-cryptenroll1: + + + + + + + See Also + + systemd1, + systemd-cryptsetup@.service8, + systemd-cryptsetup-generator8, + systemd-cryptenroll1, + fstab5, + cryptsetup8, + mkswap8, + mke2fs8 + + + + -- cgit v1.2.3