Re: [GIT PULL] Kernel lockdown for secure boot
> > There's no inherent difference, in terms of the trust chain, between > compromising it to use the machine as a toaster or to run a botnet - the > trust chain is compromised either way. But you're much more likely to > notice if your desktop starts producing bread products than if it hides > some malware and keeps on booting, and the second one is much more > That is to say, as a result of the way malware has been written, our way > of thinking about it is often that it's a way to build a boot loader for > a malicious kernel, so that's how we wind up talking about it. Are we > concerned with malware stealing your data? Yes, but Secure Boot is only > indirectly about that. It's primarily about denying the malware easy > mechanisms to build a persistence mechanism. The uid-0 != ring-0 aspect > is useful independent of Secure Boot, but Secure Boot without it falls > way short of accomplishing its goal. > > -- I am sorry the issue here this is really expanding Secure Boot to breaking point. Yes a person wants a secure system having the boot parts verified by some means and using a lockdown is advantage. Problem comes in with the idea that UEFI Secure Boot and lockdown are linked. If I am running windows and linux on the same machine Secure Boot need to be on so windows run happy. Remember its my machine. If I wish to compromise security on my machine because it make sense I should be allowed to, A proper lockdown would prevent you from messing with ACPI tables it a very creative hack have kernel load a DSDT and have it from ring zero turn bits in the kernel off. The reality here is we need to be able to operate without lockdown due to how badly broken some hardware it to configure system. Yes the need to include option to push button to disable secure boot is required due to how badly broken this stuff is. Of course this does not address the issue that if I am working on a system from remote or embedded where I don't have the push button to turn off as a option this is still a problem. Effective lockdown has to protect linux kernel boot parameters, initramfs and other bits from being modified as well. This lead us to problem with the broken hardware in a machine we cannot turn secure boot off we still need to perform all these alterations. We do not live in a world of perfect computer hardware so at this stage proper unattackable secureboot cannot be done. We would be better off putting effort into improve means with UEFI of adding own KEK. This is so that only boot loaders and kernels from the vendors user has approved in fact to work. There could also be a configuration KEK that gets disabled after all the required operating systems are installed.So Microsoft non OS KEK makes sense to be the configuration rule breaking KEK but the current deployments of UEFI don't have a off switch option on it. One KEK for everyone who is not Microsoft to boot with is highly insecure. UEFI secureboot falls way short in the validation department currently because too much is validated under one KEK key. UEFI also fall short due to failing to provide a system to protect boot parameters that can alter OS behaviour and make a secure kernel insecure this include kernels with this lockdown patches, Really you need to compare UEFI secureboot vs boot loader and /boot on a read only media. Every where you can change something in the UEFI secureboot without is being signed that you cannot in the read only media of the boot loader and /boot is a defect in the UEFI secureboot design and implementation. If boot parameters were properly secured there would be no need for lockdown query if UEFI was in secureboot mode or not. Also lockdown being on and kernel and boot loader not running secured still would provide extra item attacker has to get past. So fairly much remove the EFI interrogation patches and work with UEFI to fix it properly. Hacking around these UEFI defects means we will end up being stuck with them and the system still not being properly secured. Peter Dolding -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Kernel lockdown for secure boot
On Thu, Apr 5, 2018 at 2:26 AM, Matthew Garrett <mj...@google.com> wrote: > On Tue, Apr 3, 2018 at 11:56 PM Peter Dolding <oia...@gmail.com> wrote: >> On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett <mj...@google.com> wrote: > >> > There are four cases: >> > >> > Verified Boot off, lockdown off: Status quo in distro and mainline > kernels >> > Verified Boot off, lockdown on: Perception of security improvement > that's >> > trivially circumvented (and so bad) >> > Verified Boot on, lockdown off: Perception of security improvement > that's >> > trivially circumvented (and so bad), status quo in mainline kernels >> > Verified Boot on, lockdown on: Security improvement, status quo in > distro >> > kernels >> > >> > Of these four options, only two make sense. The most common > implementation >> > of Verified Boot on x86 platforms is UEFI Secure Boot, > >> Stop right there. Verified boot does not have to be UEFI secureboot. >>You could be using a uboot verified boot or >> https://www.coreboot.org/git-docs/Intel/vboot.html google vboot. >> Neither of these provide flags to kernel to say they have been >> performed. > > They can be modified to set the appropriate bit in the bootparams - the > reason we can't do that in the UEFI case is that Linux can be built as a > UEFI binary that the firmware execute directly, and so the firmware has no > way to set that flag. > With some of your embedded hardware boot loaders you have exactly the same problem. Where you cannot set bootparams instead have to hard set everything in the kernel image. This is why there is a option to embedded initramfs image inside kernel image because some of them will only load 1 file. So not using UEFI you run into the exact same problem. So lockdown on or off need to be a kernel build option setting default. This could be 3 options Always on, Always off and "Automatic based on boot verification system status". https://linux.die.net/man/8/efibootmgr Also I have a problem here in non broken UEFI implementations -@ | --append-binary-args that is very simple set the command line passed into UEFI binary loaded by the firmware with the Linux kernel this comes bootparams. Yes using --append-binary-args can be a pain it is used to tell the Linux kernel where to find the / drive. So turning lockdown off by bootparams is down right possible with working UEFI. There is a lot of EFI out there that does not work properly. >> Now Verified Boot on, lockdown off. Insanely this can be required in >> diagnostic on some embedded platform because EFI secureboot does not >> have a off switch.These are platforms where they don't boot if >> they don't have a PK and KEK set installed. Yes some of these is jtag >> the PK and KEK set in. > >> The fact that this Verified Boot on, lockdown off causes trouble >> points to a clear problem. User owns the hardware they should have >> the right to defeat secureboot if they wish to. > > Which is why Shim allows you to disable validation if you prove physical > user presence. Good idea until you have a motherboard where the PS2 ports have failed and does not support usb keyboard so you have no keyboard until after the kernel has booted so no way to prove physical presence. Or are working on something embedded that has no physical user presence interface in the boot stages these embedded devices can also be UEFI with secureboot. Not everything running UEFI has keyboard, screenanything that you can prove physical user presence with sometimes you have to pure depend on the signing key. If I am a person who has made my own PK and has my own KEK in UEFI system I should have the right to sign kernel with lockdown off by default. I may need this for diagnostics on hardware without user interface and I may need this because the hardware is broken and I have set PK and KEK set by direct firmware flash access possibly by jtag or possibly before critical port on motherboard died. Of course I am not saying that Microsoft and others cannot have rules that say if using their KEK that you cannot do this. But if the machine is my hardware and I have set my own PK and KEK set I do know what I am doing and I should be allowed to compromise security if I wish its my hardware. I should not have to custom hack to do it. Of course I am not saying that the setting in Linux kernel configuration system cannot have a big warning that you should not do this unless you have no other valid option and I am not saying that the kernel should not log/report if it see what appears to be a questionable configuration like dmesg "SECURITY ISSUE: UEFI secureboot detected enabled kernel built with lockdown disabled system at risk of com
Re: [GIT PULL] Kernel lockdown for secure boot
> If you don't have secure boot then an attacker with root can modify your > bootloader or kernel, and on next boot lockdown can be silently disabled. Stop being narrow minded you don't need secure boot to protect bootloader or kernel the classic is only boot from read only media. Another is network boot using https can coreboot firmware. This checks the certificate of the https server against selected CA before downloading anything and as long as the firmware is set read only in hardware the attack has absolutely nothing to work on. In fact the network boot form https server is more secure than UEFI secureboot due to highly limited parties who can alter/provide the approved boot loader/kernel image. Having root user rights does not override physical security.The fact there are other ways of doing bootloader and kernel security other than UEFI secureboot that are in lots of cases more secure than UEFI secureboot due to using more limited keys is the absolute reason why lockdown is required without UEFI secureboot. It would make sense to extend kexec to support UEFI secureboot verification and also kexec to have frameworks to support other security options like https server storage of all kernel images. Please note kexec supporting UEFI secureboot verification should also support booting non UEFI secureboot but verified by some other method and having own PK/KEK set for kexec and this would be when the Linux kernel is placed in firmware and used instead of EFI firmware.. Please note there are many UEFI firmwares that with secureboot off allow setting up secure https bootting where you are not in fact validating the boot loader or kernel but validating the source you get them from. There are three different ways to achieve a protected boot process. 1) validate the boot files.(this is like UEFI secure boot and many other methods) 2) validate source the boot files. Yes this can be apply key check to image if image is not signed don't boot from it and the image contain boot loader and kernel then not bother validating the boot loader and kernel image/parts individually same with https. 3) make boot files read only. All three achieve the same level of security. If you are using any of the three lockdown option may provide some benefit. Yes https network boot effectively does 2 and 3 so making having a very limit threat against the boot process. Remember there is more 1 way to skin a cat just like there is more than 1 way to make a secure system. Currently being too narrow in methods for doing protected booting. Peter Dolding. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Kernel lockdown for secure boot
. On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett <mj...@google.com> wrote: > There are four cases: > > Verified Boot off, lockdown off: Status quo in distro and mainline kernels > Verified Boot off, lockdown on: Perception of security improvement that's > trivially circumvented (and so bad) > Verified Boot on, lockdown off: Perception of security improvement that's > trivially circumvented (and so bad), status quo in mainline kernels > Verified Boot on, lockdown on: Security improvement, status quo in distro > kernels > > Of these four options, only two make sense. The most common implementation > of Verified Boot on x86 platforms is UEFI Secure Boot, Stop right there. Verified boot does not have to be UEFI secureboot. You could be using a uboot verified boot or https://www.coreboot.org/git-docs/Intel/vboot.html google vboot. Neither of these provide flags to kernel to say they have been performed. So Verified boot looking off to kernel yet lockdown needing to be on is one very valid combination and must be supported because the Linux kernel does not always know when it verified boot environment. When the Linux kernel thinks verified boot is off it may not be trivial to circumvent. Now Verified Boot on, lockdown off. Insanely this can be required in diagnostic on some embedded platform because EFI secureboot does not have a off switch.These are platforms where they don't boot if they don't have a PK and KEK set installed. Yes some of these is jtag the PK and KEK set in. The fact that this Verified Boot on, lockdown off causes trouble points to a clear problem. User owns the hardware they should have the right to defeat secureboot if they wish to. In fact the issue that you can not install a KEK per operating system installed shows a problem as well. So all OS use the same KEK for their installers and then you have all non Microsoft in a lot of cases the same KEK for booting OS. Any of these bootloaders/kernels with defect will end up with the security being exactly like Verified Boot on, lockdown off. Remember attackers will send around copies of what ever they need to so they can breach a system so they find a defective solution some where they will ship it everywhere. Attackers that secureboot is attempted to prevent are criminal anyhow what is a little bit of copyright violation to them.. So when the current UEFI design is security theatre there should not be any special effort to support it. If UEFI was not security theatre there would be a clean way for people install and setup up their systems to list what operating system KEK should be accepted so allowing attack surface area to be minimised and the damaged form any flawed implementation to also be limited. This way end users could opt in or out of operating systems based on security. If user has opted out of all operating systems doing Verified Boot on, lockdown off: those are not a threat. Also any OS with defective kernel or bootloader that the system has not allowed the KEK of would also not be a threat. Really I see no reason to be bending over in the Linux kernel for UEFI secureboot. You list all 4 types need to exist for different usage case of the Linux kernel. The fact UEFI secureboot currently is implemented on x86 does not handle the fact all 4 use cases need to exist is really a issue with UEFI Secureboot that needs to be fixed by those designing UEFI for the future. Allowing the kernel to be configured the 4 different ways does not mean a party like Microsoft has to sign off on everything the Linux kernel can do. Its not like android/IOT vendors have to bow to Microsoft. The Linux kernel should not show favouritism. This does mean that all 4 modes should be in the kernel configuration options. Matthew Garrett your mistake is that only 2 are valid when all 4 are valid in different usage cases.Circumventing security is sometimes required accepting that case is hard for some people. Of course when a party need perform circumventing security the fact that it currently gives out the keys to world of UEFI systems is a very big security design flaw in UEFI. Why should the Linux kernel contain code to work around defective design of UEFI and limit what users not using UEFI and using UEFI can do? Peter Dolding -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
