This option will control the use of DNR for choosing DNS servers on the
link. Defaults to the value of UseDNS so that in most cases they will be
toggled together.
This option is another way for DHCP servers to indicate preferred DNS
servers for the network, but includes more detailed info like the server
name, transport (DoT/DoH/DoQ etc.), and port.
Allow our DHCPv4 client to parse this option.
This type will be used to represent a "designated resolver", and the
necessary info for communicating with it. Beyond and address endpoint,
we may need to know the dns transport, authenticated domain name, DoH
path, etc.
The verb s not really specific to credential management, it was always a
bit misplaced. Hence move it to systemd-analyze, where we already have
some general TPM related verbs such as "srk" and "pcrs"
Monitor the sysctl set by networkd for writes, if a sysctl is
overwritten with a different value than the one we set, emit a warning.
Writes are detected with an eBPF program attached as BPF_CGROUP_SYSCTL
which reports the sysctl writes only in net/.
The eBPF program only reports sysctl writes from a different cgroup than networkd.
To do this, it uses the `bpf_current_task_under_cgroup_proto()` helper,
which will be available allowed in BPF_CGROUP_SYSCTL from kernel 6.12[1].
Loading a BPF_CGROUP_SYSCTL program requires the CAP_SYS_ADMIN capability,
so drop it just after the program load, whether it loads successfully or not.
Writes are logged but permitted, in future the functionality can be
extended to also deny writes to managed sysctls.
[1] https://lore.kernel.org/bpf/20240819162805.78235-3-technoboy85@gmail.com/
This is a rework of e7a93e7521: instead of
handling components with n_variants being zero at every step of the way, we instead
remove it from our list after loading all components, given that such a
component simply makes not sense for the rest of our logic.
If we operate in "offline" mode, i.e. know the device key, then we will
not have a TPM2 connection, hence don't try to read the PCR bank to use form
it.
We don't need it anyway because we are not going to test unseal things.
Fixes: #33855
Such a policy won't provide any protection, but it's still entirely fine
to have it like this in various contexts, for example at OS install
time, to allocate the nvindex and reference it in enrollments. However,
it does deserve mention, hence log about it at LOG_NOTICE level.
This is based on a similar patch by Arnaud Patard
<arnaud.patard@collabora.com> proposed at #33663.
These variables closely mirror the existing
LoaderDevicePartUUID/LoaderImageIdentifier variables. But the Stub…
variables indicate the location of the stub/UKI (i.e. of systemd-stub),
while the Loader… variables indicate the location of the boot loader
(i.e. of systemd-boot). (Except of course, there is no boot loader used,
in which case both sets point to the stub/UKI, as a special case).
This actually matters, as we support that sd-boot runs off the ESP,
while a UKI then runs off XBOOTLDR, i.e. two distinct partitions.
Let's always check if we have data to set *first*, and only then check
if an EFI var is already set.
Checking for the EFI var is more expensive after all.
If this is not done, and there are two images, image_1.raw and image_2.raw under
an image.raw.v folder, then the log will say "Using extensions image" instead of
using "Using extensions image_2.raw" which is the desired behavior for v-picked extensions.
Now that we have multi-profile UKIs people likely want to stick more PE
sections into them than before. Hence, bump the number of available PE
section slots to 30 (up from 15). Also, make this configurable at build
time since some folks probably want even more, and others don't want
this at all.
(pre-allocating too many shouldn't matter too much btw, I'd advise
everyone to overshoot, except maybe on the tiniest of embedded boards)
Let's make use of libcryptsetup's new crypt_token_set_external_path()
API in place of the interposition stuff we have been doing before. Let's
kill it entirely, given that this was a developer feature only anyway
(and guarded by an appropriate ifdef).
Fixes: #30098
Login shells are supposed to marked via a dash as first char. We follow
that logic, but right now we simply overwrite the first char of the
shell. That might not be the right choice, given that this turns
"zsh" into "-sh", which suggests some bourne shell process.
Hence, let's correct things, and instead prefix a dash, which should be
safer.
Inspired by findings on https://github.com/systemd/systemd/issues/34153#issuecomment-2338104907
Ronan Pigott
Luca Boccassi
Lennart Poettering
Matteo Croce
Mike Yuan
Daan De Meyer
Maanya Goenka
Yu Watanabe
Tomas Bzatek