[systemd-devel] sd-boot setup and PCRs

[Andrei Borzenkov]

On 19.06.2023 17:12, Felix Rubio wrote:
> Hi Andrei,
> 
> In that case, could happen that a malicious actor that has had in the
> past access to the systemd-boot, shim, and the UKI, comes back with
> those 3 on a USB stick and boots the machine? 

The malicious actor does not need USB. If malicious actor have physical 
access, malicious actor can simply boot your system using existing on 
disk installation.

> Then it would indeed make
> sense to bind the LUKS key to PCR 4, this making it 4+7+14, so that the
> use of outdated UKI is not possible.
> 
> Thank you!
> 
> Felix
> 
> On 2023-06-19 14:04, Andrei Borzenkov wrote:
>> 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