On Fri, Mar 14, 2014 at 4:18 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > On Fri, Mar 14, 2014 at 10:08:40PM +0000, One Thousand Gnomes wrote: >> > Signed userspace is not a requirement, and therefore any solution that >> > relies on a signed initrd is inadequate. There are use cases that >> > require verification of the initrd and other levels. This isn't one of >> > them. >> >> The job of the kernel is to solve the general problem. There are lots of >> people who happen to care about verification beyond the kernel so it >> shouldn't be ignored. And they can do do things like load trusted SELinux >> rulesets even if you can't support it in your environment. > > This is really a question about goals and trust models. Alan is > arguing that we should support trust models and goals which go far > beyond the goals and trust model of the UEFI Forum. > > Matthew is, I think, trying to make the argument that his patches > fulfill the goals that are needed so we can boot Linux distribution > kernels on UEFI secure boot machines without worrying about Microsoft > deciding to revoke keys so that Red Hat or SuSE will no longer be able > to be bootable on desktops that are certified for Windows 8. And > while we might want to improve the framework to support other trust > models later on, supporting distro kernels on Windows 8 certified PC's > is important enough that we should let these patches into mainline. > > Is that a fair summary of the two viewpoints? UEFI is a red herring in both cases. This isn't about UEFI, it just happens that one of the things that can assert "trusted_kernel" is the UEFI Secure Boot path. Chrome OS would assert "trusted_kernel" by passing it on the kernel command line (since it, along with firmware, kernel, and root fs are effectively measured). A boot-my-router-from-CD system can assert similarly because the kernel is on RO media. Based on my view of the conversation, it's about whether or not capable() can be made to do these checks. The proposal about creating the action/privilege map is interesting, and I'm all for doing it just to make things easy to reason about for capabilities, but it still seems separate from this work. There still needs to be a global boolean for the "trusted kernel" state. It would be used, for example, on the module param whitelisting, which has nothing to do with capabilities. It would be used to change driver behavior (e.g. disabling DMA or other badness that isn't trusted), which has nothing to do with capabilities. The ability to check this state is going to be needed going into the future as we uncover more dangerous interfaces. Since the capability work is separate, when it happens, that same regex work could replace some of the is_trusted_kernel checks with new action tests, but we still need the same infrastructure and identification of dangerous interfaces. Capabilities can be seen as related to this patch set, but it cannot be seen as a blocker. This logic is needed today, it's implemented, and it clearly marks where the known problems are. If an overhaul of capabilities happens, it can happen separately. -Kees -- Kees Cook Chrome OS Security -- 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
