Date: Tue, 31 May 2016 15:04:18 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Eric McCorkle <eric@metricspace.net> Cc: Allan Jude <allanjude@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: EFI GELI support ready for testers Message-ID: <20160531120418.GF38613@kib.kiev.ua> In-Reply-To: <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <d6b96a6c-4e92-35a5-e78b-cc674b6d2f25@freebsd.org> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 29, 2016 at 10:10:16AM -0400, Eric McCorkle wrote: > > Ok fine. But this is a risk anyone using EFI has to assume, and it doesn't end at the boot environment. There are plenty of nasty tricks an EFI boot environment can play that affect the OS as well. It's simply impossible for an OS to provide reliable security when the hardware or firmware is compromised, and this isn't limited to the boot loader. > This statement, althought looking true, does not account for difference in the level of efforts required to target the corresponding environment. > This kind of thing is the reason for projects like coreboot gaining traction. If you really don't trust EFI, then the right answer is to use something like coreboot, or else don't use a system with EFI. Trying to compensate for this by keeping stuff out of the boot loader (and exposing vital parts of your system in a powered-off state) is futile, as a determined attacker can just set things up to compromise the kernel anyway. > No, you do not understand, or went into the protective mode where the broad statements should cover the place. I am fine with the security implications of the UEFI environment activating the kernel. I am not fine with exposing the sensitive material to UEFI boot. Same from the classic BIOS. > What you completely ignore in all this is the capability for an attacker to tamper with the unencrypted kernel, loader, and drivers. At which point would the attacker tamper ? Immediately after your GELI UEFI code provides him with the keys to do so ? > This is all academic. Yes, maybe someone can piece together what version of things I'm running. Of course, they'd have no idea what my address map looks like, unless they can get my compiler version and custom kernel config. Maybe there's some way to do that too. > > But they get all of this with 100% accuracy by scanning the unencrypted boot partition, AND they can tamper with any of it. It's *just* less secure, plain and simple. > Ok, another 'security' theatre. Let me restate the question I aked in my first mail, but now after having the discussion rolled forward. Is there any other 'security' benefit from having /boot encrypted, other than obscuring the kernel binary ? > You are only considering one kind of scenario. Alan's and my work is aimed at protecting systems from attackers that have some level of physical access to the machines. There are people in the world who have to contend with this sort of thing, and the major competing OSes (Apple, Linux, MS, etc) all have their own full-disk encryption solutions. > > Moreover, my work is aimed at tamper-resilience at the OS level. Yes, I know OS tamper-resistance can be undermined without trusted firmware, but we are seeing projects like coreboot and others working toward that end. Moreover, these kinds of efforts are themselves pointless when the OS does things like leaving the most sensitive part of the system wide open to tampering. > > Speaking personally, I would like to see a system where I have full disk encryption combined with EFI secure boot with a unique platform key stored on my encrypted disk. Having an unencrypted boot partition in such a system just opens up more attacks, plain an simple. (I would also like to see an open source firmware and no ME, but that's out of scope here) What you describe makes even less sense. If secure boot is in action, then kernel binary should be measured and its fingerprints compared with the protected records in TPM. Then all the layers that you add are useless. > > Finally, it's not like Alan's and my work *forces* anyone to use GELI. If you are really worried about some scenario where an attacker doesn't have physical access and needs to backdoor the firmware to sniff keys so they can access data they can't see despite being able to write to firmware, then fine, don't use GELI at boot. Better yet, use the compile flag to remove it from boot1 and loader completely. But if you want full disk encryption, you have the option of having it. It forces us to maintain that code. It pulls large amount of code into environment that is hard to debug in the comfortable local setup, and is absolutely impossible to inspect and diagnose in the wild, where the problems occur on the user machine. All that cost for the only 'security' provided not exposing the kernel binary.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160531120418.GF38613>