Closed Bug 1470597 Opened Last year Closed 4 months ago

[macOS 10.14] Investigate enabling Hardened Runtime

Categories

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

62 Branch
Unspecified
macOS
defect

Tracking

()

RESOLVED DUPLICATE of bug 1471004
Tracking Status
firefox62 --- affected

People

(Reporter: haik, Assigned: haik)

References

(Blocks 3 open bugs)

Details

(Keywords: sec-want)

Attachments

(1 file, 1 obsolete file)

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.
See Also: → mojave
(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.
(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.
(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.
Blocks: 1470607
(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.
Blocks: mojave
See Also: mojave
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?
Flags: needinfo?(haftandilian)
(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.
(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.
Flags: needinfo?(haftandilian)
Blocks: 1474447
(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.
Summary: [macOS 10.14] Investigate enabling Enhanced Runtime for the parent process → [macOS 10.14] Investigate enabling Enhanced Runtime
Blocks: 1474451
See Also: → 1378417
Priority: -- → P2
Depends on: mojave-sdk
(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.
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.
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.
No longer depends on: mojave-sdk
Assignee: nobody → haftandilian
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.
Attachment #9030012 - Attachment is obsolete: true
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.
Summary: [macOS 10.14] Investigate enabling Enhanced Runtime → [macOS 10.14] Investigate enabling Hardened Runtime

(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.

Blocks: catalina
No longer blocks: mojave

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.

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1471004
You need to log in before you can comment on or make changes to this bug.