pcrlock: be more careful when preparing credential name for pcrlock policy
The .cred suffix is stripped from a credential as it is imported from
the ESP, hence it should not be included in the credential name embedded
in the credential.
journald: mention the access mode we tried to open /dev/kmsg in
Let's make clearer what we are going to use /dev/kmsg for: read/write or just
writing. This hopefully should avoid confusion, such as the one #33975
is result of.
(Also while we are at it, add one extra debug message).
cryptenroll/cryptsetup: allow combined signed TPM2 PCR policy + pcrlock policy
So far you had to pick:
1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor
blesses your setup via signature)
or
2. Use a pcrlock policy (i.e. local system blesses your setup via
dynamic local policy stored in NV index)
It was not possible combine these two, because TPM2 access policies do
not allow the combination of PolicyAuthorize (used to implement #1
above) and PolicyAuthorizeNV (used to implement #2) in a single policy,
unless one is "further upstream" (and can simply remove the other from
the policy freely).
This is quite limiting of course, since we actually do want to enforce
on each TPM object that both the OS vendor policy and the local policy
must be fulfilled, without the chance for the vendor or the local system
to disable the other.
This patch addresses this: instead of trying to find a way to come up
with some adventurous scheme to combine both policy into one TPM2
policy, we simply shard the symmetric LUKS decryption key: one half we
protect via the signed PCR policy, and the other we protect via the
pcrlock policy. Only if both halves can be acquired the disk can be
decrypted.
This means:
1. we simply double the unlock key in length in case both policies shall
be used.
2. We store two resulting TPM policy hashes in the LUKS token JSON, one
for each policy
3. We store two sealed TPM policy key blobs in the LUKS token JSON, for
both halves of the LUKS unlock key.
This patch keeps the "sharding" logic relatively generic (i.e. the low
level logic is actually fine with more than 2 shards), because I figure
sooner or later we might have to encode more shards, for example if we
add further TPM2-based access policies, for example when combining FIDO2
with TPM2, or implementing TOTP for this.
Apparently _PATH_UTMPX is a glibc'ism. UTMPX_FILE is the same thing and
what everyone else uses. Since they are otherwise equivalent, let's just
switch.
We generally use utmpx instead of utmp (both are actually identical on
Linux, but utmpx is POSIX, while utmp is not). Let's fix one left-over
case.
UT_NAMESIZE does not exist in utmpx world, it has no direct counterpart,
hence let's just sizeof_field() to determine the size of the actual
field. (which comes to the same result of course: 32).
In https://github.com/systemd/systemd/pull/5283/commits/924453c22599cc246746a0233b2f52a27ade0819
ProtectHome was set to true for systemd-coredump in order to reduce risk, since an attacker could craft a malicious binary in order to compromise systemd-coredump.
At that point the object analysis was done in the main systemd-coredump process.
Because of this systemd-coredump is unable to product symbolicated call-stacks for binaries running under /home ("n/a" is shown instead of function names).
However, later in https://github.com/systemd/systemd/commit/61aea456c12c54f49c4a76259af130e576130ce9 systemd-coredump was changed to do the object analysis in a forked process,
covering those security concerns.
Let's set ProtectHome to read-only so that systemd-coredump produces symbolicated call-stacks for processes running under /home.
This also
- rename variable n -> address,
- use log_syntax_parse_error() where applicable,
- add one more assertion for lvalue in config_parse_address().
hwdb: Mark Apple Wireless keyboards as not having NumLock LED
Mark those Apple Wireless keyboards as not having a NumLock key:
https://en.wikipedia.org/wiki/Apple_Wireless_Keyboard
You can see that they don't have a NumLock LED because they didn't even
have a NumLock in the first place:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0fea6fe7d5ef1b5fa5f78048d4729f85181c04ca
The identifier 'stdin' is reserved in C. It can be #defined to any
statement that evaluates to a FILE*. We do not want that for our field,
so change to a more descriptive name.
Peter Rajnoha [Thu, 5 Sep 2024 10:31:20 +0000 (12:31 +0200)]
udev: allow persistent storage rules for rbd devices
The RADOS Block Device (rbd) can be used as any other block device with
further layers on top of it, hence allow the common persistent storage
rules to apply, including watching for changes.
time-util: rework localtime_or_gmtime() into localtime_or_gmtime_usec()
We typically want to deal in usec_t, hence let's change the prototype
accordingly, and do proper range checks. Also, make sure are not
confused by negative times.
Do something similar for mktime_or_timegm().
This is a more comprehensive alternative to #34065
Michael Ferrari [Thu, 6 Jun 2024 14:06:34 +0000 (16:06 +0200)]
firstboot: reduce log level of timezone validation
An error message is already printed directly after, so the user already
knows that the validation failed. This also isn't done for the other
validation functions.
Michael Ferrari [Wed, 5 Jun 2024 17:33:19 +0000 (19:33 +0200)]
firstboot: add newline before key wait
When sd-firstboot is ran during first boot of a new system this missing
newline leads to a bootup message being appended on the same line as the
message instructing to press a key.
Mike Yuan [Wed, 28 Aug 2024 17:46:22 +0000 (19:46 +0200)]
core/unit: introduce unit_set_debug_invocation()
Given that debug_invocation is a Unit thing, make
service_set_debug_invocation() generic. Plus, don't
say "Service failed", as it would be spurious when
Restart=always.
Daan De Meyer [Fri, 23 Aug 2024 11:40:40 +0000 (13:40 +0200)]
copy: Introduce COPY_NOCOW_AFTER and use it when copying images
When dealing with copying COW images, we have to make a tradeoff:
- Either we don't touch the NOCOW bit on the copied file COW and get
an instant copy because we're able to reflink, but we might get
reduced performance if the source file was COW as COW files and lots
of random writes don't play well together.
- Or we force NOCOW for the copied file, which means we have to do a
full copy as reflinking from COW files to NOCOW files or vice versa
is not supported.
In exec-invoke.c, we've opted for the first option. In nspawn.c and
discover-image.c, we've opted for the second option.
In nspawn, this applies to the --ephemeral option to make ephemeral
copies. In discover-image.c, this applies to cloning images into
/var/lib/machines. Both these features might be used to run many
machines of the same original image. We really don't want to force
a full copy onto users in these scenarios when they're expecting
reflink behavior, leading to them running out of disk space. Instead,
degraded performance in their machines is a much less severe issue,
which they will discover on their own if it affects them, at which
point they can make their original image NOCOW at which point they'll
get both the reflinks and better performance.
Given the above reasoning, let's switch nspawn.c and discover-image.c
to use COPY_NOCOW_AFTER as well instead of enabling NOCOW upfront and
forcing a copy if the original source image is COW.
Daan De Meyer [Fri, 23 Aug 2024 11:04:33 +0000 (13:04 +0200)]
copy: Copy nocow flag by default
Unless otherwise requested, if we're going to copy a nocow file, make the
target file nocow as well.
Aside from keeping the performance characteristics of the cow or nocow file
intact, reflinking also only works from cow to cow or nocow to nocow files.
Reflinking from cow to nocow or nocow to cow files does not work and can
easily lead to unexpected copies for users, so by keeping the nocow bit
intact across copies by default we also make sure reflinks always work.