Open Bug 1356167 Opened 3 years ago Updated 2 years ago

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

Categories

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

55 Branch
Unspecified
macOS
enhancement

Tracking

()

Tracking Status
firefox55 --- affected

People

(Reporter: haik, Assigned: haik)

References

(Depends on 1 open bug)

Details

(Whiteboard: sb+)

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.
Assignee: nobody → haftandilian
Whiteboard: sbmc2
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.
Whiteboard: sbmc2
(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.
Whiteboard: sbmc3
Depends on: 1334550
See Also: → 1376814
P2 seems right since this is blocked by 'post-57-api-changes'.
Priority: -- → P2
Whiteboard: sbmc3 → sb+
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
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
Priority: P2 → P3
Flags: needinfo?(haftandilian)

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 mochikit@mozilla.org.xpi, special-powers@mozilla.org.xpi. 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.

Flags: needinfo?(haftandilian)
You need to log in before you can comment on or make changes to this bug.