Let's introduce a common implementation of a function that checks
whether we are booted on a kernel with systemd-stub that has TPM PCR
measurements enabled. Do our own userspace measurements only if we
detect that.
PCRs are scarce and most likely there are projects which already make
use of them in other ways. Hence, instead of blindly stepping into their
territory let's conditionalize things so that people have to explicitly
buy into our PCR assignments before we start measuring things into them.
Specifically bind everything to an UKI that reported measurements.
This was previously already implemented in systemd-pcrphase, but with
this change we expand this to all tools that process PCR measurement
settings.
The env var to override the check is renamed to SYSTEMD_FORCE_MEASURE,
to make it more generic (since we'll use it at multiple places now).
This is not a compat break, since the original env var for that was not
included in any stable release yet.
The systemd-growfs@.service units are currently written in full for each
file system to grow. Which is kinda pointless given that (besides an
optional ordering dep) they contain always the same definition. Let's
fix that and add a static template for this logic, that the generator
simply instantiates (and adds an ordering dep for).
This mimics how systemd-fsck@.service is handled. Similar to the wait
that for root fs there's a special instance systemd-fsck-root.service
we also add a special instance systemd-growfs-root.service for the root
fs, since it has slightly different deps.
Fixes: #20788
See: #10014
if we want generators to instantiate a template service, we need to
teach generator_add_symlink() the concept.
Just some preparation for a later commit.
While we are at it, modernize the function around
path_extract_filename() + path_extract_directory()
These options allow measuring the volume key used for unlocking the
volume to a TPM2 PCR. This is ideally used for the volume key of the
root file system and can then be used to bind other resources to the
root file system volume in a secure way.
See: #24503
When measuring data into a PCR we are supposed to hash the data on the
CPU and then pass the hash value over the wire to the TPM2. That's all
good as long as the data we intend to measure is not sensitive.
Let's be extra careful though if we want to measure sensitive data, for
example the root file system volume key. Instead of just hashing that
and passing it over the wire to the TPM2, let's do a HMAC signature
instead. It's also a hash operation, but should protect our secret
reasonably well and not leak direct information about it to wiretappers.
Currently, sd-dhcp-server accepts spurious client IDs, then the leases
exposed by networkd may be invalid. Let's make networkctl gracefully
show such leases.
Fixes#25984.
When the target (Where=) of a mount does not exist, systemd tries to
create it. But previously, it'd always been created as a directory. That
doesn't work if one wants to bind-mount a file to a target that doesn't
exist.
Fixes: #17184
During the credentials encryption, if systemd it is compiled with TPM2
support, it will try to use it depending on the key flags passed.
The current code only checks if the system has a functional TPM2 if the
case of the INITRD flag.
This patch do a similar check in the case that it is outside initrd (but
still automatic).
Signed-off-by: Alberto Planas <aplanas@suse.com>
In make_credential_host_secret, the credential.secret file is generated
first as a temporary anonymous file that is later instantiated with
linkat(2). This system call requires CAP_DAC_READ_SEARCH capability
when the flag AT_EMPTY_PATH is used.
This patch check if the capability is effective, and if not uses the
alternative codepath for creating named temporary files.
Non-root users can now create per-user credentials with:
export SYSTEMD_CREDENTIAL_SECRET=$HOME/.config/systemd/credential.secret
systemd-creds setup
Signed-off-by: Alberto Planas <aplanas@suse.com>
Now that we have ukify and mkosi has been updated to use it, we
have a solution in place to make sure that PE sections don't overlap
in a UKI so let's drop the workaround to avoid overlapping PE sections.
We likely always want to open the directory via a slink.
There's currently only one caller so it doesn't make any difference in practice
but I think it's still nicer.
No functional change.
Previously mere MemoryLow= directive would lead to emitting the compat
message 'Applying MemoryMax=18446744073709551615 as MemoryLimit=' even
though it carries little information.
Let's explicitly let btrfs know when we're done using a loop device.
Otherwise, btrfs will keep the device UUID cached which will result
in mount() failures if we ever generate a device or filesystem with
the same UUID again.
When a new wireless network interface is created by the kernel, it emits
both RTM_NEWLINK and NL80211_CMD_NEW_INTERFACE. These events can arrive
in either order and networkd must behave correctly in both cases.
The typical case is that RTM_NEWLINK is handled first, in which case
networkd creates a Link object and starts tracking it. When the
NL80211_CMD_NEW_INTERFACE message is handled, networkd then populates
the Link object with relevant wireless properties such as wireless
interface type (managed, AP, etc.).
In the event that the order is reversed however, networkd will fail to
populate these wireless properties because at the time of processing the
nl80211 message, the link is considered unknown. In that case, a debug
message is emitted:
systemd-networkd[467]: nl80211: received new_interface(7) message for link '109' we don't know about, ignoring.
This is problematic because after the subsequent RTM_NEWLINK message,
networkd will have an incomplete view of the link. In particular, if a
.network configuration matches on some of the missing wireless
properties, such as WLANInterfaceType=, then it will never match.
The above race can be reproduced by using the mac80211_hwsim driver.
Suppose that there exists a .network configuration:
[Match]
WLANInterfaceType=ap
...
Now loop the creation/destruction of such an AP interface:
while true
do
iw dev wlan0 interface add uap0 type __ap
iw dev uap0 del
done
The above debug message from networkd will then be observed very
quickly. And in that event, the .network file will fail to match.
To address the above race, have the nl80211 message handler store the
interface index in a set in case a Link object is not found on
NL80211_CMD_NEW_INTERFACE. The handler for RTM_NEWLINK can then query
this set, and explicitly request the wireless properties from nl80211
upon the creation of the Link object.
