Re: Trusted kernel patchset

[Matthew Garrett]

On Mon, 2015-03-16 at 14:45 +0000, One Thousand Gnomes wrote:
> On Fri, 13 Mar 2015 11:38:16 -1000
> Matthew Garrett <matthew.garrett@xxxxxxxxxx> wrote:
> 
> > 4) Used the word "measured"
> > 
> > Nothing is being measured.
> 
> Nothing is being trusted either. It's simple ensuring you probably have
> the same holes as before.
>
> Also the boot loader should be measuring the kernel before it runs it,
> thats how it knows the signature is correct.

That's one implementation. Another is the kernel being stored on
non-volatile media.

> On other points:
> 
> - your sysfs node is useless. I can mount over it to fake trusted and
>   fool apps even in a supposedly "trusted" environment - it has to be a
>   syscall I think so anything sensitive can invoke it directly from
>   statically bound code and get a true answer.

The sysfs node isn't intended to be used as a mechanism for userspace to
determine whether the kernel is trustworthy - there's clearly no way to
do that, since anyone able to launch an untrusted kernel can simply
modify it so that it lies there. It exists so that people deploying some
form of trusted boot chain can enable the lockdowns while still within
the trusted codebase. If you want to prove trustworthiness then you're
still going to need something like TPM-based attestation.

> - there are devices that do things triggered on read cycles. It might not
>   be a bad idea to lock down reading mem and kmem too

Yeah, at the very least doing that for anything mapped as a device is
entirely reasonable. Let me look at that.

> - All suspend/resumes allow modifying the kernel. I can boot Linux
>   suspend, boot windows, modify the Linux restore image, boot Linux and
>   own the box. You would need to sign the resume image somehow I think or
>   just disable all suspend/resume

I'm kind of torn on this - yes, there are deployment scenarios where
hibernation can be used to circumvent the restrictions, but there are
also scenarios where that can be avoided (eg, the bootloader verifies
some state with respect to the hibernation image).

> - Why pick on ASUS WMI - every magical firmware interface has this
>   property, and given how bad most firmware is I'd be more worried about
>   access to things like UEFI services or straight forward ACPI methods.

The ASUS WMI driver basically allows the execution of an entirely
unknown set of SMI calls, whereas all the other drivers execute a
curated subset of functions. Specific platforms may have specific bugs,
but in general we control access to firmware calls quite strictly.

>   Also consider user access to GPIO pins. You can do some very
>   interesting things on certain machines with those, such as glitching
>   device power rails for a few microseconds.

Good point. In general there's also the risk that GPIOs may be used for
features like TPM physical presence detection, so exposing those to
userspace does seem like a bad idea.

> What you don't document is the assumption about how the kernel boot
> parameters are handled. A large number of boot parameters allow arbitrary
> I/O access or allow code execution if used with skill and cunning.

Things that spring to mind here:

1) The ability to disable IOMMUs (some handwaving about the number of
machines that still don't have IOMMUs because security is a perfectly
reasonable thing to perform product differentiation on I guess?)
2) Your previous concerns about being able to manipulate the memory map
in hostile ways
3) Drivers that allow users to tell the kernel devices exist at
arbitrary memory addresses and then benefit from probe routines that
write blindly

Are there any other categories you're worried about? I have made an
effort to audit the generic kernel options and the only ones I'm
especially worried about in category (3) are the earlyprintk ones, but
obviously there's a bunch of old drivers that allow arbitrary addresses
to be passed and cleaning those up would be worth it.