Proposed F19 Feature: Package Signature Checking During Installation

[Peter Jones]

On Wed, Jan 09, 2013 at 11:55:42AM +0100, Florian Weimer wrote:
> On 01/08/2013 07:15 PM, Peter Jones wrote:
> >On Tue, Jan 08, 2013 at 11:04:30AM -0500, Steve Clark wrote:
> >>
> >>What about repins? I want to add my own custom package that is not signed and create a new CD with a custom ks.cfg.
> >>How would that work?
> >
> >You'd generate your own key, and people using your packages, who have
> >presumably decided they trust that you're really you through some other
> >method, would enrol your key in the MoK list on the machine.  Alternately
> >you can pay $99 (one time only) and get your keys signed by something the
> >machine already trusts.
> 
> I don't think this is how it works.  Earlier descriptions confirm
> what you wrote, but to my knowledge, they do not describe the actual
> process.  The $99 certificate is used to authenticate to Microsoft
> only, and Microsoft produces a completely unrelated signature on the
> blob you submit, using a certificate of their own.  Without this
> additional step, the $99 certificate is just as good as any other.
> A new blessing has to be obtained for every new blob.

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 ...".

> You'd also have to rebuild the entire chain, which is quite a bit of
> effort just for a custom kickstart configuration.

And you've misunderstood the question - this is if you want to use
custom packages in your repo that aren't built in our build system.

> 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.

> 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.

-- 
        Peter