CentOS/Fedora use annobin which will complain if FORTIFY_SOURCE=0
is used so we disable those checks to avoid the warnings.
We also make sure that when we query the compilation flags so we can
add more, we set _fortify_level=0 and undefine _lto_flags so that we
don't get those flags in the result.
Subscribe() enables full signal delivery on API bus. But aside from
that, if a unit/job is explicitly Ref()'d, manager also emits the
signal. See bus_foreach_bus() for details.
bus-wait-for-units refs every unit to wait for, so there's no need
to Subscribe() on top of that. In verb_clean_or_freeze() Subscribe()
is not called either.
According to copy_file_range (2), errno will be set to EOPNOTSUPP when
the file system does not support copy_file_range(). Since there is
already fallback logic in place here for other kinds of errors, add
-EOPNOTSUPP to the list of ignored errors.
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.
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.
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.
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!
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.
See TPM2 spec, Part 3, Section 12.3.1
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.
