On Fri, 1 Mar 2013, Matthew Garrett wrote: > > > If you've loaded an x.509 certificate into the kernel and it's later > > > revoked, any module signed with the key is going to be loadable until > > > it's revoked. I don't see an especially large difference here? > > > > i_own_your_ring0.ko can be modprobed long after blacklisting of "hello > > world" binary hash has happened on the very particular machine in its dbx > > (as there is no link, in a x509-chain-of-trust-sense, between the hash of > > the PE binary and the i_own_your_ring0.ko signature key). > > Ah, I see what you mean. Yes, we should probably keep track of the > linkage between the original hash and the key in the kernel and then > invalidate the key if a corresponding dbx update is pushed,
That will at least make the blacklisting work properly, yes. It of course still doesn't fix the principal problem, that you are artificially changing the signature semantics of "Microsoft trusts this binary" to "we claim that Microsoft actually meant that they trust this key". That has very little to do with proper X509 cryptography. But at least we are on a same page now. Thanks, -- Jiri Kosina SUSE Labs -- 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/
