This adds a new switch try-empty-password. If set and none of PKCS#11 or
key files work, it is attempted to unlock the volume with an empty
password, before the user is asked for a password.
Usecase: an installer generates an OS image on one system, which is the
booted up for the first time in a possibly different system. The image
is encrypted using a random volume key, but an empty password. A tool
that runs on first boot then queries the user for a password to set or
enrols the volume in the TPM, removing the empty password. (Of course, in
such a scenario it is important to never reuse the installer image on
multiple systems as they all will have the same volume key, but that's a
different question.)
Let's make loading of keys a bit more automatic and define a common
place where key files can be placed. Specifically, whenever a volume of
name "foo" is attempted, search for a key file in
/etc/cryptsetup-keys.d/foo.key and /run/cryptsetup-keys.d/foo.key,
unless a key file is declared explicitly.
With this scheme we have a simple discovery in place that should make it
more straightfoward wher to place keys, and requires no explicit
configuration to be used.
This is useful when the key file is acquired dynamically in some form
and should be erased after use.
Note that this code tries to be robust, and removes the key file both on
success and on failure.
This way we can take benefit of the correct block device locking we just
added.
I was thinking whether to instead pull in a regular
systemd-makefs@.service instance, but I couldn't come up with a reason
to, and thus opted for just doing the minimal patch and just replacing
the simply mkfs calls.
Fixes: #10179
Replaces: #13162
This adds a new crypttab option for volumes "pkcs11-uri=" which takes a
PKCS#11 URI. When used the key stored in the line's key file is
decrypted with the private key the PKCS#11 URI indiciates.
This means any smartcard that can store private RSA keys is usable for
unlocking LUKS devices.
This option is an indication for PID1 that the entry in crypttab is handled by
initrd only and therefore it shouldn't interfer during the usual start-up and
shutdown process.
It should be primarily used with the encrypted device containing the root FS as
we want to keep it (and thus its encrypted device) until the very end of the
shutdown process, i.e. when initrd takes over.
This option is the counterpart of "x-initrd.mount" used in fstab.
Note that the slice containing the cryptsetup services also needs to drop the
usual shutdown dependencies as it's required by the cryptsetup services.
Fixes: #14224
The code was using timeout=0 as the default option string. This option string
was ultimately passed to generator_write_timeouts(), which only looks for
comment=systemd.device-timeout= or x-systemd.device-timeout=, i.e. the whole
call path was bogus. Let's rework this: generator_write_timeouts() now writes
any timeouts if configured by the user. create_disk() writes out it's own
timeout, but with lower priority. Since the code path that was calling
timeout=0 was not effective, the only change is that we stop overwriting the
timeout if explicitly configured by the user.
In both code paths, ignore failure to write.
cryptsetup introduced optional locking scheme that should serialize
unlocking keyslots which use memory hard key derivation
function (argon2). Using the serialization should prevent OOM situation
in early boot while unlocking encrypted volumes.
Note that this slightly changes behaviour: "none" is only allowed as
option, if it's the only option specified, but not in combination with
other options. I think this makes more sense, since it's the choice when
no options shall be specified.
I added a fairly vague entry to docs/ENVIRONMENT because I think it is worth
mentioning there (in case someone is looking for any environment variable that
might be relevant).
libcryptsetup v2.0.1 introduced new API calls, supporting 64 bit wide
integers for `keyfile_offset`. This change invokes the new function
call, gets rid of the warning that was added in #7689, and removes
redundant #ifdefery and constant definitions.
See https://gitlab.com/cryptsetup/cryptsetup/issues/359.
Fixes#7677.
This reverts a part of commit 49fe5c0996 ('tree-wide: port various places
over to STARTSWITH_SET()') that replaced a pair of startswith() calls
with STARTSWITH_SET().
They were in fact for a different strings (device vs. name), botching
the crypttap parsing.
prefix_root() is equivalent to path_join() in almost all ways, hence
let's remove it.
There are subtle differences though: prefix_root() will try shorten
multiple "/" before and after the prefix. path_join() doesn't do that.
This means prefix_root() might return a string shorter than both its
inputs combined, while path_join() never does that. I like the
path_join() semantics better, hence I think dropping prefix_root() is
totally OK. In the end the strings generated by both functon should
always be identical in terms of path_equal() if not streq().
This leaves prefix_roota() in place. Ideally we'd have path_joina(), but
I don't think we can reasonably implement that as a macro. or maybe we
can? (if so, sounds like something for a later PR)
Also add in a few missing OOM checks
Fixes#12650
cryptsetup: Extract dependency check to a separate function
cryptsetup: style improvements, error checking
Return early on failure/nothing to do
Removed braces from single-line ifs
Check return value of fstab_filter_options
cryptsetup: code style
LUKS2 supports so-called tokens. The libcryptsetup internally
support keyring token (it tries to open device using specified
keyring entry).
Only if all token fails (or are not available), it uses a passphrase.
This patch aligns the functionality with the cryptsetup utility
(cryptsetup luksOpen tries tokens first) but does not replace
the systemd native ask-password function (can be used the same in
combination with this patch).
The crypt_load() for LUKS2 can read a quite big area of disk
(metadata area size is configurable and can increase up to megabytes).
This initialization is not needed to be repeated, just use the existing context.
(This patch is also required for the following change.)
If crypt_load() for LUKS succeeds, we know that it is a LUKS device.
Failure of data device setting should fail in this case; remapping
as a PLAIN device late could mean data corruption.
(If a user wants to map PLAIN device over a device with LUKS header,
it should be said explicitly with "plain" argument type.)
Also, if there is no explicit PLAIN type requested and crypt device
is already initialized (crypt_data_type() is set), do not run
the initialization again.
With new LUKS2 header format it is possible to use Argon2 key derivation
function. This function is "memory-hard" hence keyslot unlocking can
potentially use a lot of RAM as this increases resistance to massively
parallel GPU based password cracking.
However, when multiple systemd-cryptsetup binaries run at the same
time it is very likely that system using Argon2 (e.g. Fedora 30)
will encounter memory-pressure during early boot, following OOM killing
spree.
This patch aims to lower the damage done by OOM killer and sets OOMScore
for systemd-cryptsetup units to 500. Hopefully OOM killer will then
shoot us down and leave rest of the system services alone.