From b30846379dea3190efa2ca4f84dc6eded895cc71 Mon Sep 17 00:00:00 2001 From: Trammell Hudson Date: Tue, 27 Sep 2016 19:53:28 -0400 Subject: [PATCH 1/3] some frequently asked questions, with draft answers --- FAQ.md | 122 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 122 insertions(+) create mode 100644 FAQ.md diff --git a/FAQ.md b/FAQ.md new file mode 100644 index 00000000..e2fe1b26 --- /dev/null +++ b/FAQ.md @@ -0,0 +1,122 @@ +Frequently Asked Questions about Heads +=== + +Why replace UEFI with coreboot? +--- +While Intel's edk2 tree that is the base of UEFI firmware is open source, +the firmware that vendors install on their machines is proprietary and +closed source. Updates for bugs fixes or security vulnerabilities +are at the vendor's convienence; user specific enhancements are likely not +possible; and the code is not auditable. + +UEFI is much more complex than the BIOS that it replaced. It consists of +millions of lines of code and is an entire operating system, +with network device drivers, graphics, USB, TCP, https, etc, etc, etc. +All of these features represents increased "surface area" for attacks, +as well as unnecessary complexity in the boot process. + +coreboot is open source and focuses on just the code necessary to bring +the system up from reset. This minimal code base has a much smaller +surface area and is possible to audit. Additionally, self-help is +possible if custom features are required or if a security vulnerability +needs to be patched. + + +What's wrong with UEFI Secure Boot? +--- +Can't audit it, signing keys are controlled by vendors, +doesn't handle hand off in all cases, depends on possible leaked keys. + + +Why use Linux instead of vboot2? +--- +vboot2 is part of the coreboot tree and is used by Google in the +Chromebook system to provide boot time security by verifying the +hashes on the coreboot payload. This works well for the specialized +Chrome OS on the Chromebook, but is not as flexible as a measured +boot solution. + +By moving the verification into the boot scripts we're able to have +a much flexible verification system and use more common tools like PGP +to sign firmware stages. + + +What about Trusted GRUB? +--- +The mainline grub doesn't have support for TPM and signed kernels, but +there is a Trusted grub fork that does. Due to philosophical differences +the code might not be merged into the mainline. And due to problems +with secure boot (which Trusted Grub builds on), many distributions have +signed insecure kernels that bypass all of the protections secure +boot promised. + +Additionally, grub is closer to UEFI in that it must have device +drivers for all the different boot devices, as well as filesystems. +This duplicates the code that exists in the Linux kernel and has its +own attack surface. + +Using coreboot and Linux as a boot loader allows us to restrict +the signature validation to keys that we control. We also have one code +base for the device drivers in the Linux-as-a-boot-loader as well +as Linux in the operating system. + + +What is the concern with the Intel Management Engine? +--- +"Rootkit in your chipset", "x86 considered harmful", etc + + +How about the other embedded devices in the system? +--- +#goodbios, funtenna, etc. + + +Should we be concerned about the binary blobs? +--- +Maybe. x230 has very few (MRC) since it has native vga init. + + +Why use ancient Thinkpads instead of modern Macbooks? +--- +coreboot support, TPM, nice keyboards, cheap to experiment on. + +How likely are physical presence attacks vs remote software attacks? +--- +Who knows. + + +Defense in depth vs single layers +--- +Yes. + +is it worth doing the hardware modifications? +--- +Depends on your threat model. + + +Should I validate the TPMTOTP on every boot? +--- +Probably. I want to make it also do it at S3. + + +suspend vs shutdown? +--- +S3 is subject to cold boot attacks, although they are harder to +pull off on a Heads system since the boot devices are constrained. + +However, without tpmtotp in s3 it is hard to know if the system is in +a safe state when the xscreensaver lock screen comes up. Is it a fake +to deceive you and steal your login password? Maybe! It wouldn't get +your disk password, which is perhaps an improvement. + + +Disk key in TPM or user passphrase? +--- +Depends on your threat model. With the disk key in the TPM an attacker +would need to have the entire machine (or a backdoor in the TPM) +to get the key and their attempts to unlock it can be rate limited +by the TPM hardware. + +However, this ties the disk to that one machine (without having to +recover and type in the master key), which might be an unacceptable risk +for some users. From b818986cb239e91516daa9ace66333ab2b8562b6 Mon Sep 17 00:00:00 2001 From: Trammell Hudson Date: Wed, 28 Sep 2016 11:13:27 -0400 Subject: [PATCH 2/3] ignore vdso fake library on fedora --- populate-lib | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/populate-lib b/populate-lib index edb4fb4c..0fc2e561 100755 --- a/populate-lib +++ b/populate-lib @@ -51,6 +51,10 @@ my $size = 0; for my $lib (keys %libraries) { + # skip vdso + next if $lib =~ /vdso/; + + warn "$lib\n"; $size += -s $lib; my $libname = basename $lib; # my $dirname = dirname "$dest/$lib"; From 9fb998bef056c8f8de99d91c1ebfb1a653f0bfef Mon Sep 17 00:00:00 2001 From: Trammell Hudson Date: Thu, 3 Nov 2016 16:45:50 -0400 Subject: [PATCH 3/3] check PGP signatures on xen, kernel and initrd (partial fix for #43) --- initrd/start-xen | 29 +++++++++++++++++++++++++---- 1 file changed, 25 insertions(+), 4 deletions(-) diff --git a/initrd/start-xen b/initrd/start-xen index db49603a..f5aa7038 100755 --- a/initrd/start-xen +++ b/initrd/start-xen @@ -1,9 +1,30 @@ #!/bin/sh mount -o ro -t ext4 /dev/sda1 /boot -exec kexec \ +die() { echo >&2 "$*"; exit 1; } + +XEN=/boot/xen-4.6.3.gz +INITRD=/boot/initramfs-4.4.14-11.pvops.qubes.x86_64.img +KERNEL=/boot/vmlinuz-4.4.14-11.pvops.qubes.x86_64 + +echo "+++ Checking $XEN" +gpgv "${XEN}.asc" "${XEN}" || die "Xen signature failed" +echo "+++ Checking $INITRD" + +gpgv "${INITRD}.asc" "${INITRD}" || die "Initrd signature failed" + +echo "+++ Checking $KERNEL" +gpgv "${KERNEL}.asc" "${KERNEL}" || die "Kernel signature failed" + +# should also check xen command line arguments! +# should also check kernel command line arguments! + +kexec \ -l \ - --module "/boot/vmlinuz-4.1.13-9.pvops.qubes.x86_64 placeholder root=/dev/mapper/qubes_dom0-root ro i915.preliminary_hw_support=1 rd.lvm.lv=qubes_dom0/root rd.luks.uuid=luks-0f662ac6-2939-48fe-bc95-f5a7e3d6fefb vconsole.font=latarcyrheb-sun16 rd.lvm.lv=qubes_dom0/swap rhgb" \ - --module "/boot/initramfs-4.1.13-9.pvops.qubes.x86_64.img" \ + --module "${KERNEL} root=LABEL=root rhgb" \ + --module "${INITRD}" \ --command-line "no-real-mode reboot=no console=vga dom0_mem=min:1024M dom0_mem=max:4096M" \ - /boot/xen-4.6.3.gz + "${XEN}" + + +echo "Ready to start Xen: run 'kexec -e' to execute it"