09.05.2025 15:45, Lennart Poettering wrote:
On Fr, 09.05.25 15:36, Andrei Borzenkov (arvidj...@gmail.com) wrote:
61;8001;1c
I know that it is documented, but that leads to rather bad user experience.
User requests specific protection via --pcr= option, pcrlock decides to skip
(some of) them and binds unlocking to just a subset of PCRs pretending that
the operation succeeded. At this point user believes that the system is
protected - while it is not. The practical case was requesting PCRs 4,7,9
(and expecting to be protected from the kernel command line change) and
getting just PCR 7 thus allowing init=/bin/sh with full access to unlocked
root.
I think that in case of explicit --pcr= argument systemd-pcrlock should
really fail if it cannot build policy that satisfies it.
Alternatively, if it does not fail it should not also skip PCRs. After all,
it is about predicting future behavior. Even if corresponding measurements
are not present in the log *now*, they may be used after reboot. The reason
to fail here would be the lack of predictions covering these PCRs, not the
lack of the actual measurements using them.
The current behavior looks more like the case for auto-detection - check
what existing measurements are covered by predictions and incorporate those
PCRs. I.e. when no explicit --pcr= option is present.
The general rule behind pcrlock is to focus on keeping things
working. i.e. if we have clear indication that locking down a PCR
means you cannot reboot, then we'll not do it, and remove the PCR from
the protection.
Then simply fail the whole operation and inform the user; let user
investigate *why* it failed and fix it (which may be as simple as
removing some PCRs from the list).
Because otherwise people will just hate us, and turn
off the whole thing. I think pcrlock is not an all-or-nothing thing:
we should apply the tightest policy we can get away with, and that's
what we do. Hence: doing as-good-as-a-we-can is a lot better here than
just to fail entirely and not apply any system integrity.
If you want explicit config use the simpler PCR protections
systemd-cryptsetup gives you, and avoid pcrlock.
I obviously want to use pcrlock to have alternatives (like being able to
boot multiple kernels). Can I get it without pcrlock?
pcrlock is *all*
about making things work in a graceful fashion: lock down as tightly
as we can get away with but not more, because breaking things is not
just awful user XP, but is also a DoS waiting to happen.
Hence, hard disagree: pcrlock is not what you appear to think it is.
(I am fine with adding a --strict-pcr= or so switch that takes a list
of PCRs that must strictly be included, but that should be used for
special cases only, never as default)
OK, as usual, two topics in one post leads to confusion. Let me repeat.
1. Always use user provided PCRs even if we cannot reliably verify that
they are actually used.
Yes, that is dangerous and should not be the default, I agree.
2. Silently ignoring user-requested list without any feedback whatsoever.
I think that behavior is not acceptable. If you cannot satisfy user
request, then do not pretend you succeeded. Let user know about it. And
have an option to fail policy creation.
