1470597 - [macOS 10.14] Investigate enabling Hardened Runtime

Status: RESOLVED DUPLICATE of bug 1471004

(Core :: Security: Process Sandboxing, defect, P2)

Description

[Haik Aftandilian [:haik]]

Enhanced Runtime is a new macOS 10.14 security option for macOS applications. Enabling it for an app enforces all executable pages must be backed by valid signed code (with exceptions for specially JIT mapped pages). And it enforces all dynamically loaded modules are signed by the same authority or Apple (with exceptions). We should investigate enabling this for the Firefox parent processes. From the information available so far[1], this would require

1) Building with the 10.14 API

2) Having JIT execute pages be mapped with the new 10.14 mmap flag MAP_JIT

3) Specifying a subset of these entitlement/exceptions

   com.apple.security.cs.allow-jit
   com.apple.security.cs.allow-unsigned-executable-memory
   com.apple.security.cs.disable-executable-page-protection
   com.apple.security.cs.disable-library-validation // For Flash and anything else not signed by Apple or Mozilla
   com.apple.security.cs.allow-dyld-environment-variables
   com.apple.security.get-task-allow // To allow the app to be debugged
   com.apple.security.device.audio-input
   com.apple.security.device.camera
   com.apple.security.personal-information.location

1. https://developer.apple.com/videos/play/wwdc2018/702/

Filed in Process Sandboxing for now, but maybe this belongs in a build category.

Comment 1

[Stephen A Pohl [:spohl]]

(In reply to Haik Aftandilian [:haik] from comment #0)
> this would require
> 
> 1) Building with the 10.14 API

Are you referring to the 10.14 SDK? If so, note that we're currently crashing immediately upon startup in the Compositor. I haven't filed a bug or investigated this because it usually takes us a considerable amount of time to update our SDK in the build system and I'm building with the 10.11 SDK instead, but we may have to prioritize this.

Comment 2

[Haik Aftandilian [:haik]]

(In reply to Stephen A Pohl [:spohl] from comment #1)
> Are you referring to the 10.14 SDK?

Yeah, I meant the 10.14 SDK. 

> If so, note that we're currently
> crashing immediately upon startup in the Compositor. I haven't filed a bug
> or investigated this because it usually takes us a considerable amount of
> time to update our SDK in the build system and I'm building with the 10.11
> SDK instead, but we may have to prioritize this.

OK, that's good to know. I think it would be good to get the bug filed now because it sounds like it will block experimenting with this.

Comment 3

[Stephen A Pohl [:spohl]]

(In reply to Haik Aftandilian [:haik] from comment #2)
> (In reply to Stephen A Pohl [:spohl] from comment #1)
> > If so, note that we're currently
> > crashing immediately upon startup in the Compositor. I haven't filed a bug
> > or investigated this because it usually takes us a considerable amount of
> > time to update our SDK in the build system and I'm building with the 10.11
> > SDK instead, but we may have to prioritize this.
> 
> OK, that's good to know. I think it would be good to get the bug filed now
> because it sounds like it will block experimenting with this.

Just a friendly heads up that fixing one SDK-related bug typically makes way to further bugs. :-) Also, there may be limitations what SDK we can use to crosscompile. You might want to reach out to :ted to find out.

Comment 4

[Haik Aftandilian [:haik]]

(In reply to Stephen A Pohl [:spohl] from comment #3)
> Just a friendly heads up that fixing one SDK-related bug typically makes way
> to further bugs. :-) Also, there may be limitations what SDK we can use to
> crosscompile. You might want to reach out to :ted to find out.

Good point. It's a big dependency with long tail bugs and the benefit might not justify the work right now.

Comment 5

[Nathan Froyd [:froydnj]]

Do the extra steps beyond the SDK (MAP_JIT, exceptions/entitlements) restrict the binary to running on 10.14 systems, or are there magic backwards compat things happening behind the scenes on older systems?

Comment 6

[Gregory Szorc [:gps]]

(In reply to Stephen A Pohl [:spohl] from comment #1)
> because it usually takes us a considerable amount of
> time to update our SDK in the build system

So we're on the same page, changing the SDK used by the build system isn't that much work: someone packages the new SDK and updates in-tree references to it. e.g. https://hg.mozilla.org/mozilla-central/file/6e8e861540e6/browser/config/tooltool-manifests/macosx64/cross-clang.manifest. Someone could package the 10.14 SDK today and provide its metadata so Try pushes could be performed against it. File a Firefox Build System :: Toolchains bug if you would like that.

The bulk of the effort to switch SDKs is changing the Firefox/Gecko code to work with the newer SDK without causing unwanted regressions. This often requires effort by a number of people across a number of teams.

Comment 7

[Haik Aftandilian [:haik]]

(In reply to Nathan Froyd [:froydnj] (away until 16 July 2018) from comment #5)
> Do the extra steps beyond the SDK (MAP_JIT, exceptions/entitlements)
> restrict the binary to running on 10.14 systems, or are there magic
> backwards compat things happening behind the scenes on older systems?

They don't restrict the binary to 10.14 systems. According to the WWDC presentation, the exceptions and entitlements for enabling the runtime protection are backwards compatible which I assume means they are ignored when the binary is run on older OS versions. For MAP_JIT, I think we would have to do an OS version check before using it. The support for MAP_JIT in XNU predates 10.14 (presumably for Mac platform code) so we wouldn't be able to test for a MAP_JIT EINVAL error on OS versions earlier than 10.14.

Comment 8

[Haik Aftandilian [:haik]]

(In reply to Haik Aftandilian [:haik] from comment #0)
> From the information available so
> far[1], this would require
> 2) Having JIT execute pages be mapped with the new 10.14 mmap flag MAP_JIT

Having the JS engine use the MAP_JIT flag isn't a strict requirement because we could still use Enhanced Runtime and opt-out of code signing protection using com.apple.security.cs.disable-executable-page-protection per the WWDC video. However, for now, the code signing restrictions appear to be the main benefit of Enhanced Runtime.

Comment 9

[Stephen A Pohl [:spohl]]

(In reply to Gregory Szorc [:gps] from comment #6)
> (In reply to Stephen A Pohl [:spohl] from comment #1)
> > because it usually takes us a considerable amount of
> > time to update our SDK in the build system
> 
> So we're on the same page, changing the SDK used by the build system isn't
> that much work: someone packages the new SDK and updates in-tree references
> to it. e.g.
> https://hg.mozilla.org/mozilla-central/file/6e8e861540e6/browser/config/
> tooltool-manifests/macosx64/cross-clang.manifest. Someone could package the
> 10.14 SDK today and provide its metadata so Try pushes could be performed
> against it. File a Firefox Build System :: Toolchains bug if you would like
> that.
> 
> The bulk of the effort to switch SDKs is changing the Firefox/Gecko code to
> work with the newer SDK without causing unwanted regressions. This often
> requires effort by a number of people across a number of teams.

My understanding is that an SDK switch requires work in cctools (this seems to be confirmed by bug 1475652 comment 6). If memory serves me right, this was our bottleneck the last time we needed to switch to a newer SDK.

Comment 10

[Gregory Szorc [:gps]]

We cross-compile from Linux to macOS today. And have been for a while.

Is there some new feature in the 10.14 SDK that introduces a new challenge to cross-compiling? If so, then yes, that could very quickly become a hard problem :/ If such a thing exists, we should establish a Firefox Build System :: Toolchains bug to track it.

Comment 11

[Haik Aftandilian [:haik]]

Removed the dependency on bug 1475652 (build with the 10.14 SDK). Apple confirmed enabling Enhanced Runtime doesn't require building with the 10.14 SDK, but it does require running the codesign command on 10.13.6 or newer.

Comment 12

[Haik Aftandilian [:haik]]

Attachment: WIP Patch to Enable Enhanced Runtime (causes startup crash)

This patch changes the Firefox Info.plist file to add the enhanced runtime keys. With the patch, we crash at startup. I haven't debugged this yet, but wanted to post the patch so others can see what I've tried. In addition to setting these flags, the binaries need to be signed with the codesign "-o runtime" option using the codesign command from the 10.13.6+ SDK.

Note that the Info.plist file is generated during the build and this patch is meant to be used for testing on a built .app bundle. Once we know the right flags, we'll change the build script to generate these flags in the Info.plist during the build.

Comment 13

[Haik Aftandilian [:haik]]

Attachment: WIP: Browser.entitlements and plugin-container.entitlements For Enabling Enhanced Runtime

I've got an enhanced runtime build working by using an entitlement file (actually one for the parent process and a another for plugin-containers) with the codesign command. i.e., running "codesign -o runtime --entitlements plugin-container.entitlements --sign ...". The attachment contains a Browser.entitlements and plugin-container.entitlements. More work needed to confirm if having content processes having a more restrictive set of entitlements works as expected and exactly which binaries in the .app need to be signed. For example, do the entitlements applied to the .app override those applied to individual executables within the .app? The same question applies to all the executables within the .app such as pingsender, updater, crashreporter, etc.

Comment 14

[Haik Aftandilian [:haik]]

In order to allow Flash to run, we have to set com.apple.security.cs.disable-library-validation=true (disabling library validation to allow loading of third party libraries) in the plugin-container entitlements. It would be nice to enable the library validation for plugin-container content processes, but we'd have to include an additional plugin-container binary (~100K) in the .app and use that to host the Flash plugin. I don't know if accessibility or (any other feature) requires that we support loading third party libraries into our processes on Mac, but that would be a possible blocker for enabling the library validation.

Comment 15

[Haik Aftandilian [:haik]]

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

In order to allow Flash to run, we have to set
com.apple.security.cs.disable-library-validation=true (disabling library
validation to allow loading of third party libraries) in the
plugin-container entitlements. It would be nice to enable the library
validation for plugin-container content processes, but we'd have to include
an additional plugin-container binary (~100K) in the .app and use that to
host the Flash plugin. I don't know if accessibility or (any other feature)
requires that we support loading third party libraries into our processes on
Mac, but that would be a possible blocker for enabling the library
validation.

This was not correct. To set com.apple.security.cs.disable-library-validation=false, we would have to add additional plugin-container binaries for the GMP and Flash plugin process and we would have to change how we launch plugin-container processes so they don't inherit the parent process entitlements.

Comment 16

[Haik Aftandilian [:haik]]

I'm closing this bug as a duplication of bug 1471004 which turned on Hardened Runtime and Notarization for Nightly channel builds. That bug also enabled Hardened Runtime for try server builds.

And we have bug 1522409 filed to tackle signing and enabling Hardened Runtime for local developer builds.