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. 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. 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) Lennart -- Lennart Poettering, Berlin
