pcrlock: rework --recovery-pin= to take three different arguments
This reworkds --recovery-pin= from a parameter that takes a boolean to
an enum supporting one of "hide", "show", "query".
If "hide" (default behaviour) we'll generate a recovery pin
automatically, but never show it, and thus just seal it and good.
If "show" we'll generate a recovery pin automatically, but display it in
the output, so the user can write it down.
If "query" we'll ask the user for a recovery pin, and not automatically
generate any.
For compatibility the old boolean behaviour is kept.
With this you can now do "systemd-pcrlock make-policy
--recovery-pin=show" to set up the first policy, write down the recovery
PIN. Later, if the PCR prediction didn't work out one day you can then
do "systemd-pcrlock make-policy --recovery-pin=query" and enter the
recovery key and write a new policy.
pcrlock: generate recovery PINs via make_recovery_key()
We already have infrastructure for generating nice recovery keys, for
the usual cryptenroll recovery keys. Let's reuse them here, as they are
nicer to read and type than the base64 encoded randomness we so far
used.
Previously valid recovery keys remain valid, in their original format.
For future enrollments we'll however have nicer, easier recovery keys to
deal with.
tpm2-util: now that we don't use PolicyAuthValue anymore, let's not set an authValue anymore for the policy nvindex
We have now switched from PolicyAuthValue to PolicySigned to control
access to the policy nvindex to. This means there's no point in setting
an authValue on the nvindex anymore, hence drop this.
pcrlock: switch access policy for nvindex to store policy in from PolicyAuthValue to PolicySigned (with an HMAC-SHA256 key)
So far the nvindex to store the pcrlock policy in was protected via a
PolicyAuthValue policy (i.e. with a simple PIN set on the nvindex).
That's a bad idea however, as it means an attacker can simply remove and
re-create the nvindex and the "name" of the nvindex does not change,
thus defeating the logic. (This is because the authValue is *not* part
of the "name" of an nvindex!).
Fix this by switching from PolicyAuthValue to PolicySigned with an
HMAC-SHA256 key. Behaviour is very similar: however, the PIN is now part
of of the access policy hash, which *is* part of the "name" of an
nvindex. Thus, if an attacker removes and recreates the nvindex it has
to provide the same PIN again or the "name" of the nvindex will change.
Mission accomplished.
I'd like to thank Chris Coulson for finding this issue (and helping me
address it). Thank you!
tpm2-util: load external key into NULL hierarchy if private key is provided
If we load an external key into the TPM we must do so in the NULL
hierarchy. An external key after all is one that is not wrapped by any
hierarchy's seed.
Just some renaming. I found the old name a bit confusing since it sounds
as if this would get the pin from somewhere, but it really doesn't. It
just converts a PIN into an auth_value, and I think saying so explicitly
makes things easier to grok.
Richard Maw [Sat, 3 Feb 2024 14:56:42 +0000 (14:56 +0000)]
mkosi: Extend default device timeout to 20 seconds
A moderately heavily loaded system booting an image without a rootfs
may timeout before the root device appears.
20 seconds is enough for a VM with 2 CPUs and 2GB RAM.
I just realized that we should not serialize the number
of internal enum, as that's subject to changes and such
changes would be hard to notice. Let's serialize strings
properly instead.
Max Staudt [Wed, 17 Apr 2024 06:30:44 +0000 (15:30 +0900)]
udev: permanent symlinks with USB revision for /dev/media*
As a follow-up in the style of: 873be895ed ("udev: add USB revision in ID_PATH")
this patch adds a second symlink for media controllers, this time
including the USB revision.
This means that in addition to persistent symlinks like:
pci-0000:04:00.3-usb-0:1:1.0-media-controller -> ../../media0
We now also get:
pci-0000:04:00.3-usbv2-0:1:1.0-media-controller -> ../../media0
...which helps distinguish media devices plugged into different USB root
hubs provided by the same PCI card, at least as long as they are for
different USB revisions.
Fixes: 04f19d6735 ("udev: Add /dev/media/by-path symlinks for media controllers")
mkosi: Install debug packages when WITH_DEBUG=1 is enabled
When we're building debuginfo packages, the original binaries and
libraries are stripped so make sure we install the debuginfo
packages to make sure debugging in the container/VM still works.
mkosi: Setup --ffile-prefix-map= for opensuse as well
This doesn't actually work because the opensuse spec doesn't allow
adding extra build flags, but I'm working on fixing that, so let's
already set things up for later.
systemctl: show invocation ID in unit status output
I think we should put more emphasis on the invocation ID as a handle for
a specific runtime cycle of a unit. Let's start with actually showing it
to users.
Since 56b2970 has proven to be a no-go for us, as it breaks existing
links, let's embrace the trailing slash and use absolute links
everywhere for our pages. This way we'll get around browser cleverly
appending the relative link to the current location (since it ends with
a slash), and given our docs/ layout is flat it's not much of a hassle
either.
Converted using this beauty:
$ sed -ri 's/(\[.+\]\()([A-Z_]+\))/\1\/\2/g' *.md
-Og still causes a lot of "<optimized out>" in GDB so let's use -O0
instead and disable FORTIFY_SOURCE as it doesn't work without
optimizations enabled.
mkosi: Set up -ffile-prefix-map= correctly when building debuginfo packages
This makes sure that the debuginfo files contain source files pointing
to the source files shipped by the debugsource package.
Normally this should be done automatically by rpm invoking debugedit
but for some unknown reason debugedit refuses to rewrite the source
files in our binaries.
Given that debugedit is completely undebugable (does not generate any
logs at all, and its source code is ridiculously obtuse), let's set
-ffile-prefix-map= when building instead which achieves the same
effect.
Otherwise, even if we have already received RA, timeout callback will be
called. Currently, networkd mostly does nothing on timeout, hence should
not change any effective behavior.
projects / thirdparty / systemd.git / log
