[systemd-devel] sd-boot setup and PCRs

[Andrei Borzenkov]

On 19.06.2023 10:19, Felix Rubio wrote:
> "Signed by whom?" - Signed by an actor trusted by Secure Boot, either at
> the platform level, or by any of the Shim contributors (I have not
> checked yet if it comes with a list of certificates, or only contains
> the one I enrolled)
> 
> "What is \"your certificate\"?" - The one I generated and enrolled into
> MOK.
> 

In this case PCR 14 will not change. PCR 4 will include measurement of 
the binary loaded by shim. So if you place the same version of 
systemd-boot binary on USB it is up to the systemd-boot. The shim readme 
states that PCR 4 will be extended with "the hash of any binary for 
which Verify is called through the shim_lock protocol". So as long as 
systemd-boot calls shim to verify UKI you need the same UKI binary to 
unlock encrypted device. Which is not much different from simply booting 
from hard disk.

I am not familiar with details of UKI implementation, but if it is 
possible to override kernel command line, you can trivially boot into 
/bin/sh unless you also bind LUKS key to the PCR 12 (or whatever is used 
to measure kernel parameters).

> Regards!
> 
> Felix
> 
> On 2023-06-19 06:26, Andrei Borzenkov wrote:
>> On 18.06.2023 21:56, Felix Rubio wrote:
>>> Hi everybody,
>>>
>>> After some days offline, today I have gone through the emails
>>> exchanged
>>> a couple of weeks ago and agreed: UKI is the way to go. Last time I
>>> checked about it I read about possible problems related to when some
>>> modules would be loaded and so, but I see that my knowledge was
>>> outdated.
>>>
>>> This said, right now my setup looks like: SecureBoot is enabled, I am
>>> using Shim, Systemd-Boot as shim's second stage, and a UKI. As the
>>> disk
>>> is encrypted, for now I am making the decryption predicated to PCRs 7
>>> and 14, so that the decryption will only fail when either SB state
>>> changes, or when shim certificates/hashes change. So far so good.
>>>
>>> Out of curiosity now, I am wondering: what would happen in case
>>> somebody
>>> boots the system from, e.g., a USB drive that contains a signed image?
>>
>> Signed by whom?
>>
>>> Even if the shim is the same version, I assume it will fail to unlock
>>> because the MOK will not contain my certificate?
>>
>>
>> What is "your certificate"?
>>
>>> Should that certificate
>>> had been stolen and present, be enough to then unlock the disk?
>>>
>>> I am trying to assess if I should put in the mix PCR 4, so that I can
>>> keep track of the UKI image that gets loaded. Do you guys think this
>>> would be needed, or is overkill?
>>>
>>> Regards,
>>>
>>> Felix