On Fr, 09.05.25 15:58, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > > 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).
This stuff is supposed to run automatically, on systems managed by people who are not TPM gurus. Sorry, but pcrlock is explicitly about being automatic and safe, not about pushing problems to users. > > 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? No. > > 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. Hmm, event_log_reduce_to_safe_pcrs() logs about each PCR it drops with LOG_NOTICE? Heck it even logs at LOG_INFO which PCRs it managed to keep in. Lennart -- Lennart Poettering, Berlin
