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

[Andrei Borzenkov]

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.