On 01/09/2013 03:26 PM, Peter Jones wrote:
You've misunderstood the mechanism at work. dhowell's current kernel
patch set allows you to add keys which are wrapped (in a well defined
way) in a pecoff binary that's signed by already trusted keys. This is
what I'm referring to above when I say "get your keys signed by ...".
Oh dear, what a horrible kludge. But I admit that it might work,
assuming that Microsoft signs that nonsensical (from their perspective)
key-wrapping binary.
I don't think relying on Secure Boot is the best way to secure the
installation path. Theoretically, it is feasible, but it will
always be brittle.
Citation needed.
See my direct follow-up to Jaroslav's initial message.
Those who cannot use Secure Boot (because they
lack the hardware or rely on kernel features disabled by Secure
Boot) should have access to a secure installation path, too.
I'd be perfectly happy if you found another mechanism to gain a
verifiable root of trust we can use and submit that as your own feature
to implement. As you've not taken the first 13 years of opportunity to
do so, I'm going to move along with my solution until I hear legitimate
reasons it won't work.
I certainly welcome these efforts. At least one part of it (teaching
anaconda to verify (downloaded) packages against included key material)
will be required by any other solution.
--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
