Matthew Garrett <mjg59@xxxxxxxxxxxxx> writes: > On Sun, Nov 04, 2012 at 09:14:47AM +0000, James Bottomley wrote: > >> I've actually had more than enough experience with automated installs >> over my career: they're either done by paying someone or using a >> provisioning system. In either case, they provision a static image and >> boot environment description, including EFI boot services variables, so >> you can provision a default MOK database if you want the ignition image >> not to pause on firstboot. > > And now you've moved the attack vector to a copy of your provisioning > system instead. > >> There is obviously the question of making the provisioning systems >> secure, but it's a separate one from making boot secure. > > You don't get to punt on making the kernel secure by simply asserting > that some other system can be secure instead. The chain of trust needs > to go all the way back - if your security model is based on all installs > needing a physically present end user, all installs need a physically > present end user. That's not acceptable, so we need a different security > model. Bzzzt. Theory and reality disagreeing. I have done a lot of automatic installs. At the very least someone has to be present to apply power to the hardware. So someone being present is not a requirement you can remove. Furthermore in most cases an automatic install requires kicking the system into network boot mode or into inserting an install cd. Both are actions that require a user to be present. The goal is to reduce what a user must do to a minimum to remove the possibility of human error, not to reduce what must happen into absurdity. The other side is that a general purpose configuration of firmware almost never is suitable for a general install. So either some small amount of time must be spent fixing the BIOS settings or have an appropriate set of BIOS settings come from your supplier. In practice what I would expect of a UEFI system that ships ready for automatic installs is a system that initiall boots up in "setup mode" where it is possible to install your own platform signing key. What I would expect to happen in that situation is that during the first boot software would come over the network or from an install cd and install my platform signing key. Then a bootloader signed with my key would be installed, and then everything would chain from there. In most cases where I would be setting up an automatic install I would not install Microsoft's key, and I would definitely not sign my bootloader with Microsoft's key. At most I would sign my own "key install" with Microsoft's key. Then in cases of automatic reinstallation my key would be in the firmware and I could change my bootloader and my kernels at will with no risk that some third party could do anything to the machine unless they manged to get physical access. If I was a distroy my key would that I would install by default would be the distro's signing key. Although honestly I would still prefer a solution where I could lock things down a little farther. In any case the notion that unattended install with no user interaction on any uefi machine in any state is complete and total rubbish. It can't be done. You need power and you need boot media. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
