Re: Trusted kernel patchset

[One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>]

On Fri, 13 Mar 2015 11:38:16 -1000
Matthew Garrett <matthew.garrett@nebula.com> 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.

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.

- 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

- 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

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

I think this looks a lot better. It's still security theatre but fixing
that requires actually fixing the rest of the kernel 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.

Alan