Re: Trusted kernel patchset for Secure Boot lockdown

[Kees Cook <keescook@chromium.org>]

On Fri, Mar 14, 2014 at 4:18 PM, Theodore Ts'o <tytso@mit.edu> 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