Re: Trusted kernel patchset

[Kees Cook]

On Mon, Mar 16, 2015 at 11:15 AM, Matthew Garrett
<matthew.garrett@xxxxxxxxxx> wrote:
> 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.

I really think "trusted" is the right term here. It's about as
accurate as possible for what this flag means. In the same way that
nothing is ever bug-free, nothing can be perfect. The word "measured"
isn't right for this series because it is a subset of "trusted". We
trust the kernel is some specific thing, trusted (to some level)
externally. It's trusted to be "known good". Some implementations can
even revoke that trust via a number of ways (roll-back protection,
e.g.), so it doesn't have to mean "trusted forever" either.

>> 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.

_Everything_ can be faked from userspace. I can ptrace-intercept
syscalls and fake out a return value too. Having it as an
informational tool has benefits for how a userspace tool may want to
react to discovering it can't fiddle with some blocked interface, for
example.

>> - 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.

I've always been creeped out that userspace and go examine PCI space. :)

>> - 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).

We have no system yet to validate hibernation images, so it's correct
to disable hibernation images that lack validation (which is all of
them).

>> - 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.

And if we find more terrible interfaces, we add them to this "blacklist".

>>   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.

Possibly the SPI driver too.

>> 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.

I still say that a trusted kernel includes its boot parameters. This
is true in the Chrome OS case, as parameters are part of the verified
kernel boot block, but it could be a concern for someone who has built
a grub-based CDROM or something and didn't lock the grub menu down. I
think, though, that those things need to be part of documentation, not
code, as this point.

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/