IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
Follow-up for 8c15bf36e117054cf54b4f0cca59615b7531a545
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.
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")
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.
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.
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.
See: #16035
Clarify that `-p, --priority=` always treats its option as a priority range, even when given
a single log level per the full man page description.
Co-authored-by: Mike Yuan <me@yhndnzj.com>
