Attacking the kernel via its command line

Posted Jun 21, 2017 2:20 UTC (Wed) by thestinger (guest, #91827)
In reply to: Attacking the kernel via its command line by thestinger
Parent article: Attacking the kernel via its command line

> 2) firmware

This can provide value if there's a Trusted Execution Environment with either dedicated storage and/or hardware-bound keys accessible to it but not the OS. It protects data stored there even if the attacker gets control over the OS. It's just that jumping to 3 or 4 but not any further doesn't really add anything compelling...

> 4) firmware / bootloaders / kernel

And "kernel" includes verifying the kernel line... unless you make it fully untrusted. It doesn't include protecting the kernel from the OS. That's not really part of verified boot.

to post comments

Attacking the kernel via its command line

Posted Jun 21, 2017 2:25 UTC (Wed) by thestinger (guest, #91827) [Link]

> It doesn't include protecting the kernel from the OS. That's not really part of verified boot.

At least in the lines below where init and SELinux policies, etc. are verified and cannot be disabled, so protection of the kernel happens via userspace, which must be verified regardless to guarantee anything useful...

Anyway, it all seems pretty clear to me. I don't see what's missed. Not going to bother trying to explain it further though. I already stated on this on the list and it was just ignored here, so what's the point?