[Go Faster] Default system add-ons and signing
axel at mozilla.com
Sun Sep 20 08:23:28 UTC 2015
On 9/19/15 12:33 AM, Dave Townsend wrote:
> At the moment the plan is to include the most recent versions of any
> system add-ons with Firefox at build time. We're also expecting all
> system add-ons to be signed by a special signing root. These two
> things don't work out so well together. Unless we check in signed
> versions of system add-ons whenever they change then developers doing
> local builds won't be able to run the system add-ons, also we'll have
> to figure out some way for releng builds to sign the add-ons before
> packaging the app. The problems are larger for linux distros doing
> their own builds. None of that sounds good.
> Instead I propose that we don't require the system add-ons that ship
> with the app to be signed (the updates that download mid-cycle would
> still be signed of course). None of the rest of the Firefox code is
> signed so I don't know that we need to sign these other bits. We do
> still want to make it difficult for malicious apps to use this as a
> means to inject code into Firefox. The current client code assumes
> these system add-ons just live as XPIs in a directory in the
> installation directory and any new XPI dropped in would be used by
> Firefox (unless we've already downloaded some new system add-ons
> mid-cycle). If we're concerns that that is too easy a target there are
> a couple of options we could use:
> One option is to instead embed the system add-ons inside omni.ja.
> *This probably has some nice performance wins* as it is but it means
> that in order to inject a new system add-on in an attacker must alter
> omni.ja, and if they're willing to do that then they can just turn off
> the signing requirements or even just edit browser.js already anyway.
The mere possibility that we'll get perf wins here to me is a reason to
not go down the omni.ja route. If that was the case, we'd ship a perf
regression to our release audience every first update-after-update.
We'd also have no perf testing on this in our standard testing
infrastructure, as that's testing the builds we produce.
And there'd be hardly any pre-release audience testing the code path and
perf characteristics of our release audience (well, at least not after
the first update-after-update). 'Cause our nightly audience will only
ever be on bundled versions, so will aurora. Same might still hold true
(update-after-update means the first add-on update after a firefox
update. no idea if we have a term for that)
> An even simpler option is to leave the XPIs where they are but include
> a file listing the expected add-ons and maybe their hashes in omni.ja.
> Again attackers would have to manipulate omni.ja to have any effect,
> it would be a simpler attack but it would also be much much simpler to
> implement this option.
> Any concerns or other ideas for this? How much protection do we feel
> we need to put in place around the default system add-ons?
I have an additional question: How do these proposals map to
> Gofaster mailing list
> Gofaster at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gofaster