linux-kernel - Re: Trusted kernel patchset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Mar 2015 14:45:04 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Matthew Garrett <matthew.garrett@...ula.com>
Cc:	linux-security-module@...r.kernel.org, james.l.morris@...cle.com,
	serge@...lyn.com, linux-kernel@...r.kernel.org,
	keescook@...omium.org, hpa@...or.com
Subject: Re: Trusted kernel patchset

On Fri, 13 Mar 2015 11:38:16 -1000
Matthew Garrett <matthew.garrett@...ula.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/