May 4, 2014
Participants: Andy Lutomirski, Dave Jones, H. Peter Anvin, James Bottomley, Jiri Kosina, and, Josh Triplett.
People tagged: Alan Cox, Matthew Garrett.
Mention of secure boot prompted Josh Boyer to ask if last year's “What to do about the secure_modules/trusted_kernel/whatever patch set that distros are carrying to support Secure Boot?” topic should be reprised, given that progress along these lines appeared to have been derailed again. Jiri Kosina believes that the only remaining issues surround kexec/kdump. Josh feels that Alan seems to completely disagree with the approach to security, and that this dissent has prevented some patches from making it into the security tree. James Bottomley pointed out that re-engineering of the Linux secure-boot process is being discussed in a UEFI forum, which is currently UEFI confidential. James suggested that people who are interested in this discussion contact their employer's UEFI rep (Peter Jones for Red Hat). One aspect of this discussion is the separation of Linux secure-boot policy from Microsoft's binary-signing requirements, which James hopes will cause time currently spent debating about keeping Microsoft happy to be instead spent on making better use of secure boot. James will try to arrange for permission to be granted for this topic to be discussed at Kernel Summit. Josh was happy to hear this, but noted that the objectionable portions of Matthew's patches had nothing to do with Microsoft key signing. James Bottomley said that some are suspicious that anything done anywhere in the area of secure boot is done to please Microsoft. Therefore, code that seems unrelated to key signing might nevertheless fall under suspicion. Removing questions of Microsoft proxies from the debate should therefore help raise the level of discussions surrounding secure boot.
Andy Lutomirski questioned what he described as a policy of letting user code do whatever it wanted as long as the kernel itself was not compromised. Josh Triplett advised against giving up on securing userspace, but pointed out that that it is worth enforcing boundaries between userspace and kernel, even for root users. Hence, Josh believes that Matthew's patches are quite worthwhile. Andy asked whether the boundaries between root and kernel would prevent root from rewriting the kernel boot image, from kexec'ing a new kernel, from starting a KVM instance with direct hardware access, from directly accessing controller hardware, from reading all of physical memory, and so on. Andy then suggested an alternative goal of “root shall not be able to persistently compromise the machine”. H. Peter Anvin pointed out that this implies that the kernel will need to prevent even root from executing selected function, resulting eventually in a list of restrictions and exceptions. Andy argued that the set of restrictions would be quite small, limited to things that might interfere with the verified boot process the next time. In other words, Andy is OK with root preventing the next boot from happening due to secure-boot validation failures, but expects secure boot to detect any tampering, even from root user. The only arguments that Andy has heard for why the kernel should protect itself from root are (1) Microsoft and Verisign demand it, and (2) It is annoying to fool a user into thinking that they correctly booted some other OS when they are really running Linux. Andy does not think much of either argument. Josh Triplett responded that (1) is useful if you want to boot Linux on modern systems without BIOS configuration. Josh also argues that annoying attackers can have value when that annoyance translates into increased cost, raising the cost of purchasing systems for botnets, citing “An Agenda for Empirical Cyber Crime Research“ in the 2011 USENIX Annual Technical Conference. James Bottomley suggested that the kernel community stop focussing on (1) because second-guessing these companies can be non-productive and also because there might be a secure-boot solution on the horizon that removes the Microsoft issue [see above]. James can also be agnostic on the issue of the kernel defending itself against root, in part because he has never had a break-in that escalated to root, so having the kernel protect itself against root would not have helped him. That said, James notes that the attackers did manage to cause quite enough damage despite not gaining root, and that his respose was via iptables instead of via secure boot.
Andy said that we are close to being able to pushing most services into user namespaces, which should prevent owning the kernel, barring bugs. Josh agreed with this direction, but noted that "barring bugs" is a very high bar, especially given that we are nowhere near fixing all system-call vulnerabilities. Josh also pointed out that systemd can help configure services to assist with namespace-isolated services.