Here is the thing if you are using the shim to start mok you are depending that nothing ever signed by Microsoft third party KEK has been compromised and if it has the dbx has been updated to block it. So this arguement that attacker will not be able to use a different so it is possible that attacker might be able to start a unsigned kernel using something that is already signed that is compromised.
This is the attack surface area problem. Reason why suggesting use MOK to disable secureboot to disable lock-down is invalid in a lot of cases as well.
"Both of which could be compromised after an attacker adds the option and livepatches the kernel."
The signed lockdown kernel might be broken because someone has played with linux kernel boot parameters that are not secure by UEFI. It would really make sense if kernel boot parameters were required to be signed by something. Also system accepting compromised signed boot loader from someone might also see you signed lockdown kernel livepatched.
The reality here is without taking over the PK and installing distribution own KEK that the distribution can control booting a kernel with lockdown enabled is mostly a false sense of security we can depend on compromised signed parts turn up at time point. To reduce risk of compromised signed parts requires limiting installed KEK and taking over PK.
There is no reason why a non lockdown kernel cannot be signed with a different KEK if user decides not to enrol that KEK then it will not work.
There is another reason why you only want to boot signed parts. It called validation. A non lockdown kernel is just as at risk from storage media failure as a lockdown kernel. Problem a signed kernel will detect if you have a disc failure on your hands effecting the kernel. Why the kernel will not pass signature check.
UEFI Secureboot is not just about securing the boot process. Its about validating the files loaded to make sure they have not been damaged. This damaged does not need to be done by an attacker this damage can be done by general hardware failure. So not providing a signed version of a non lockdown kernel you are leaving person open to hardware issues that would have been detected if the kernel had signed and validated by UEFI secureboot.
Yes UEFI should support less trusted KEKs. So you enrol less trusted KEK depending on the EFI configuration this could require user approval to continue boot.
Secureboot validation has a role even without lockdown. Problem is UEFI does not provide a clean interface so throws the baby out with the bath water when you disable secureboot.
Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59's journal
Re: You're not making much sense
Date: 2018-04-06 09:46 pm (UTC)Here is the thing if you are using the shim to start mok you are depending that nothing ever signed by Microsoft third party KEK has been compromised and if it has the dbx has been updated to block it. So this arguement that attacker will not be able to use a different so it is possible that attacker might be able to start a unsigned kernel using something that is already signed that is compromised.
This is the attack surface area problem. Reason why suggesting use MOK to disable secureboot to disable lock-down is invalid in a lot of cases as well.
"Both of which could be compromised after an attacker adds the option and livepatches the kernel."
The signed lockdown kernel might be broken because someone has played with linux kernel boot parameters that are not secure by UEFI. It would really make sense if kernel boot parameters were required to be signed by something. Also system accepting compromised signed boot loader from someone might also see you signed lockdown kernel livepatched.
The reality here is without taking over the PK and installing distribution own KEK that the distribution can control booting a kernel with lockdown enabled is mostly a false sense of security we can depend on compromised signed parts turn up at time point. To reduce risk of compromised signed parts requires limiting installed KEK and taking over PK.
There is no reason why a non lockdown kernel cannot be signed with a different KEK if user decides not to enrol that KEK then it will not work.
There is another reason why you only want to boot signed parts. It called validation. A non lockdown kernel is just as at risk from storage media failure as a lockdown kernel. Problem a signed kernel will detect if you have a disc failure on your hands effecting the kernel. Why the kernel will not pass signature check.
UEFI Secureboot is not just about securing the boot process. Its about validating the files loaded to make sure they have not been damaged. This damaged does not need to be done by an attacker this damage can be done by general hardware failure. So not providing a signed version of a non lockdown kernel you are leaving person open to hardware issues that would have been detected if the kernel had signed and validated by UEFI secureboot.
Yes UEFI should support less trusted KEKs. So you enrol less trusted KEK depending on the EFI configuration this could require user approval to continue boot.
Secureboot validation has a role even without lockdown. Problem is UEFI does not provide a clean interface so throws the baby out with the bath water when you disable secureboot.