1576733 - [macOS] Disclaim native messaging helper applications when launching

Status: VERIFIED FIXED

(WebExtensions :: General, enhancement, P1)

Description

[Haik Aftandilian [:haik]]

On macOS, now that Firefox is signed with Hardened Runtime enabled, native messaging helper applications which are launched using posix_spawn(2) and are children of the parent Firefox process, inherit the Firefox Hardened Runtime entitlements and limitations. Meaning that some functionality can be blocked in the helper application. Our Hardened Runtime settings are not very restrictive at this time so regressions are not likely, but we did hit one regression with bug 1570581.

In bug 1570581, enabling Hardened Runtime regressed Adobe's Acrobat webextension helper by preventing it from using Apple Events. This was addressed by allowing the Apple Event entitlement, but as we enable more restriction Hardened Runtime settings, we don't want to change the runtime environment for helper applications. If we could launch the helper applications so they are not child processes on macOS, for example using macOS Launch Services, that would prevent the helpers from inheriting Firefox's Hardened Runtime settings.

Bug 1471004 enabled Hardened Runtime and Notarization (which requires Hardened Runtime).

Comment 1

[Haik Aftandilian [:haik]]

The Hardened Runtime configuration Firefox uses is in the tree in production.entitlements.xml.

https://searchfox.org/mozilla-central/source/security/mac/hardenedruntime/production.entitlements.xml

Comment 2

[Kris Maglione [:kmag]]

This is probably a good idea, but it's also easier said than done, and would likely require rewriting significant parts of the Subprocess helper modules.

It's also worth noting that we generally want the native messaging helpers to be treated as sub-processes of Firefox so that they're killed when it is. It would be unfortunate if we started leaving around zombie helper applications when Firefox exits uncleanly...

Comment 3

[Haik Aftandilian [:haik]]

Thanks for the additional details.

I plan to update https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging with a bit of information about this. If/when we are in a position to use more strict Hardened Runtime settings, we'll have to look closely at this.

Comment 4

[Haik Aftandilian [:haik]]

rsesek@Chromium found and explained an undocumented posix_spawn attribute that might be used here as a workaround instead of using LaunchServices with our own daemon. See https://bugs.chromium.org/p/chromium/issues/detail?id=945969

Comment 5

[Kris Maglione [:kmag]]

That should make this considerably easier to fix.

Comment 6

[Haik Aftandilian [:haik]]

(In reply to Haik Aftandilian [:haik] from comment #0)

On macOS, now that Firefox is signed with Hardened Runtime enabled, native messaging helper applications which are launched using posix_spawn(2) and are children of the parent Firefox process, inherit the Firefox Hardened Runtime entitlements and limitations. Meaning that some functionality can be blocked in the helper application. Our Hardened Runtime settings are not very restrictive at this time so regressions are not likely, but we did hit one regression with bug 1570581.

While Firefox's Hardened Runtime entitlements do influence the helper behavior in this case, it isn't correct to say that Hardened Runtime entitlements are inherited. This was a misunderstanding I had. On macOS, these decisions (in this case, whether or not to allow the spawned helper application to send AppleEvents to an application) involve an attribution chain. When launching Firefox from Terminal.app, the native message helper application chain links back to Firefox and then to the Terminal. Starting with the application making the request, the TCC system appears to use an algorithm working back along the chain if necessary until it can decide if the request should be allowed or denied. For Adobe's helper application using AppleEvents, TCC stops at Firefox and uses its Hardened Runtime entitlements to allow/deny the operation. Adobe's helper application is not signed to enable Hardened Runtime or to enable any entitlements .

One can use the log command to stream TCC events and see the attribution chain: $ log stream --debug --predicate 'subsystem == "com.apple.TCC"'.

Launching the helper using the posix_spawn attribute from comment 4 (and with the AppleEvent entitlement removed) did allow Adobe's extension to work again and the TCC events logged showed the attribution chain not resolving back to Firefox.

I have a patch that changes Subprocess.jsm to use the disclaim attribute I'll post shortly. I have not found a straightforward method that could be used in a regression test to validate that a helper has been launched disclaimed.

Also it should be noted that without using the disclaim attribute to launch helpers, if a spawned process triggers a permission dialog and the user allows the operation, that decision is saved by TCC as attributed to Firefox. It would be better if that was not the case because helpers are not controlled by Mozilla or part of Firefox and the decision made affects whether or not the user will be prompted if Firefox triggers the same permission dialog. And (like the Chromium issue in comment 4) it may also make sense to launch Flash and the GMP processes using disclaim. I'll file a linked bug to address that.

Comment 7

[Haik Aftandilian [:haik]]

Attachment: Bug 1576733 - Part 1 - Launch native messaging helper applications with the "disclaim" posix_spawn attribute r?kmag!

On macOS, launch native messaging helper apps with a new "Transparency, Consent, and Control" (TCC) attribution chain using the undocumented disclaim posix_spawn attribute.

Comment 8

[Haik Aftandilian [:haik]]

Attachment: Bug 1576733 - Part 2 - Remove the Hardened Runtime AppleEvent entitlement r=spohl

Revert bug 1570581 by removing the AppleEvent entitlement from our hardened runtime configuration for both production and development.

Now that native messaging helpers are started 'disclaimed' with a new attribution chain, the entitlement is not needed.

Depends on D48028

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4ab691bf4228
Part 1 - Launch native messaging helper applications with the "disclaim" posix_spawn attribute r=kmag
https://hg.mozilla.org/integration/autoland/rev/12df7898b0ee
Part 2 - Remove the Hardened Runtime AppleEvent entitlement r=spohl

Comment 10

[Cristian Brindusan [:cbrindusan]]

Backed out 2 changesets (Bug 1576733) for android build bustages on OSFileConstants.cpp.

Backout: https://hg.mozilla.org/integration/autoland/rev/47f54345d70497eae2dba2c4cdb89175d5c06761

Push that started the failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&revision=12df7898b0eee9b11ed6189769f2a6199d93d4e1&selectedJob=274693413

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=274693413&repo=autoland&lineNumber=24552

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cbb0f17943ae
Part 1 - Launch native messaging helper applications with the "disclaim" posix_spawn attribute r=kmag
https://hg.mozilla.org/integration/autoland/rev/0cf565692fa1
Part 2 - Remove the Hardened Runtime AppleEvent entitlement r=spohl

Comment 12

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/cbb0f17943ae
https://hg.mozilla.org/mozilla-central/rev/0cf565692fa1

Comment 13

[Miruna Curtean]

Hello,

Will this fix require manual validation? If yes, please provide some steps to reproduce in order to correctly test it and also, please set the "qe-verify+" flag. Otherwise, could the "qe-verify-" flag be added? Thanks!

Comment 14

[Haik Aftandilian [:haik]]

(In reply to Miruna Curtean from comment #13)

Will this fix require manual validation? If yes, please provide some steps to reproduce in order to correctly test it and also, please set the "qe-verify+" flag. Otherwise, could the "qe-verify-" flag be added? Thanks!

Done. Thanks.

We want to validate that WebExtensions using native messaging continue to work and that bug 1570581 is still fixed.

This bug fix changed the way we launch the native messaging helper applications (used in some WebExtensions) and validating the fix is present requires looking at the log generated by $ log stream --debug --predicate 'subsystem == "com.apple.TCC"'.

However, I think it's sufficient to verify that the Adobe Acrobat extension continues to work and we don't see the problems reported on bug 1570581. See bug 1570581 comment 0 for steps to validate the fix hasn't caused bug 1570581 again. Essentially, we want to test that the user can convert a web page to PDF using the extension and that Adobe Acrobat program is opened and displays the new PDF.

Comment 15

[Miruna Curtean]

Verified fixed on macOS Catalina 10.15 with FF Nightly 72.0a1 (20191120094758).
I've converted several different pages (some which had an appropriate format such as wikipedia pages or news articles, or others like firefox homepage).
The converted PDF is launched in Adobe Reader and successful results were obtained by converting more pages in a row.
In the extensions's context menu the Conversion Successful message is displayed and a button to "Open PDF in Acrobat" after the extension has converted and downloaded the file. Clicking on "Open PDF in Acrobat" launched Adobe Acrobat and opens the PDF in a new tab.