[PM-16530] [BRE-283] Changes to support hardening on the Mac desktop app

[brant-livefront]

🎟️ Tracking

BRE-283
VULN-37

📔 Objective

This PR adds support for the Mac desktop app to use Runtime Hardening. In addition, it adds a few exceptions that allow for the app to work when hardened.

Background

The current MAS build uses sandboxing (which is a requirement for MAS) but does not implement Apple's runtime hardening. This was reported in VULN-37. To verify the hardening, you can look at the output of codesign:

codesign -d --entitlements :- --verbose=4 Bitwarden.app

The following line contains the info on hardening, specifically the flags element:
CodeDirectory v=20500 size=780 flags=0x10000(runtime) hashes=13+7 location=embedded

• When runtime hardening is enabled, it will have flags=0x10000(runtime) as it does above.
• When runtime hardening is not enabled (as is the case with the current MAS build) it will simply show flags=0x0(none).

Hardening vs. Sandboxing

Sandboxing

• Focuses on access and limiting what the app can do and how it interacts with the system
• Required for MAS (without special exceptions)
• Not required for notarizing (i.e. distribution outside the Mac AppStore)

Hardening

• Focuses on security at runtime, making the app more resistant to exploits.
• Not required for MAS, but encouraged
• Required for notarization

The net effect of this PR is to make sure the MAS app has both Sandboxing and the Hardened Runtime.

Hardening Exceptions

The hardened runtime offers several exceptions to the runtime. This allows apps to adopt the hardened runtime even if they need to do specific things that the runtime would prevent.

This PR adds one exception: com.apple.security.cs.allow-jit. This exception allows the app to run Just-In-Time compiled code. Since the app is built on electron, we need to be able to allow for typescript execution as part of the normal functioning.

All of the other aspects of runtime hardening are in full force and do not need an exception to function.

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Protected functional changes with optionality (feature flags)
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team

🦮 Reviewer guidelines

• 👍 (:+1:) or similar for great changes
• 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
• ❓ (:question:) for questions
• 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
• 🎨 (:art:) for suggestions / improvements
• ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
• 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
• ⛏ (:pick:) for minor or nitpick changes

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[bitwarden-bot]

Thank you for your contribution! We've added this to our internal Community PR board for review.
ID: PM-16530
Link: https://bitwarden.atlassian.net/browse/PM-16530

Details on our contribution process can be found here: https://contributing.bitwarden.com/contributing/pull-requests/community-pr-process.

[github-actions]

Checkmarx One – Scan Summary & Details – e9c530ed-55c6-48bd-ad20-3f3cec369ec8

No New Or Fixed Issues Found