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