[systemd-devel] systemd-pcrlock silently ignores user requested PCRs downgrading security

[Andrei Borzenkov]

09.05.2025 15:45, Lennart Poettering wrote:
> On Fr, 09.05.25 15:36, Andrei Borzenkov (arvidjaar at 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.