Re: Native Messaging (Was: Core API Proposal)

On Sun, May 8, 2016 at 10:25 PM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

>   You have reasonable points about the limits of the current security
> model for native messaging, but I think these limits are well understood
> and that the system implemented in Chrome represents current best practices
> with those limits in mind.
>
>
> Well, off-list contacts with Google core security folks indicate something
> else.  Native Messaging isn't considered as a "solution", it is rather a
> "last resort" for people who have made huge investments in the previous
> extension mechanism.  That is, that the deployment scheme for Native
> Messaging is awkward, is (according to the same sources) only good, because
> it *discourages people from developing new native extensions*.
>

I think we have a pretty big disconnect here and I suspect that it stems
from not having agreement on the purpose/goals of native messaging.  If you
define the purpose of native messaging as "provide a convenient way to
safely run arbitrary native code" then I can certainly understand why you
would be disappointed with the current capabilities.  But the actual goals
are much more modest.  I'm not sure how to really state them concisely but
something like "provide a controlled way to communicate with native
applications that fits within the limits of the existing security/trust
model for native applications".

To state the obvious, meeting the first goal is really part of a larger
unsolved problem and trying to solve that large problem is extraordinarily
ambitious.  I don't mean to dissuade you from pursuing it, but it is quite
removed from the much more modest, pragmatic goals of the native message
standardization project.


> It is also pretty obvious that an extension scheme using native code where
> the native code is unknown by the publisher (Google), isn't really
> targeting the mass market.  That there's no cryptographic binding between
> the extension and the native executable indirectly tells the same.
>

I don't agree with this at all.  Password managers are a great example of
widely used extensions that can use native messaging today.  I don't really
understand the first sentence above,.  I don't know if Google has a
relationship with the vendors of password management applications, but the
native messaging mechanism doesn't require them to have a relationship and
I think that is desirable and worth maintaining.

As for "cryptographic bindings", the native manifest declares what
extensions are allowed to access it.  In Firefox, an extension is digitally
signed, so the native executable can trust that the only extensions that
will be allowed to communicate with it are those that the author has
explicitly authorized.  There is not currently a mechanism for verifying in
the opposite direction (ie for the extension to verify the executable it is
communicating with) but an attacker who could replace the native executable
has a level of access that they could use to initiate many other attacks.
Nevertheless, there is a proposal to use code signing facilities from the
underlying platforms to allow extensions to verify native executables to
cover this scenario.

-Andrew