1356167 - [Mac] Remove $PROFILE/extensions read access from level 3 content sandbox

Status: NEW

(Core :: Security: Process Sandboxing, enhancement, P3)

Description

[Haik Aftandilian [:haik]]

This is 1-line a follow up to Bug 1354674 to remove $PROFILE/extensions from the read access whitelist. Once Bug 1334550 is fixed, content shouldn't need to read from the profile extensions directory.

Comment 1

[Haik Aftandilian [:haik]]

This bug is not just dependent on Bug 1334550, but it will likely also have to wait for build 57 when only WebExtensions are supported (per current plan) and presumably the e10s AddOn shim can be retired. This is because the e10s AddOn shim installs files in $PROFILE/extensions and then addons can them read them directly from content. Only moz-extension protocol loads will be remoted by 1334550 so this type of access won't be covered.

A test for this is toolkit/components/addoncompat/tests/browser/browser_addonShims.js which fails when $PROFILE/extensions read-access is disabled.

Comment 2

[Haik Aftandilian [:haik]]

(In reply to Haik Aftandilian [:haik] from comment #1)
> This bug is not just dependent on Bug 1334550, but it will likely also have
> to wait for build 57 when only WebExtensions are supported (per current
> plan) and presumably the e10s AddOn shim can be retired. This is because the
> e10s AddOn shim installs files in $PROFILE/extensions and then addons can
> them read them directly from content. Only moz-extension protocol loads will
> be remoted by 1334550 so this type of access won't be covered.
> 
> A test for this is
> toolkit/components/addoncompat/tests/browser/browser_addonShims.js which
> fails when $PROFILE/extensions read-access is disabled.

I misspoke here. Legacy addons will of course still need $PROFILE/extensions read access and that isn't related to the Addon Shim.

Comment 3

[Jim Mathies [:jimm]]

P2 seems right since this is blocked by 'post-57-api-changes'.

Comment 4

[Alex Gaynor [:Alex_Gaynor]]

Note to self, this also includes removing the:

; Per-user and system-wide Extensions dir
  (allow file-read*
      (home-regex "/Library/Application Support/[^/]+/Extensions/[^/]/")
      (regex "/Library/Application Support/[^/]+/Extensions/[^/]/"))



rules

Comment 5

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 6

[Haik Aftandilian [:haik]]

It appears we still need to whitelist $PROFILE/extensions because tests install system addons there, but we shouldn't need it for WebExtensions. On my systems I found [e-mail], [e-mail]. Bug 1393805 added a whitelisted directory on Mac, Windows, and Linux to use for installing legacy system addons and we might be able to move these addons there for testing instead. It's not in the profile directory:

Windows:
<user_home>\AppData\Roaming\Mozilla\SystemExtensionsDev

Mac:
~/Library/Application Support/Mozilla/SystemExtensionsDev

Linux:
~/.mozilla/systemextensionsdev

Will file a blocking bug on this after I look into it some more.