Add macOS Security Overview

[friadev]

Want to cover FileVault, App Sandbox, Hardened Runtime, XProtect, Gatekeeper, Notarization, threat models for each

Disclosure: I copied/used parts of https://github.com/drduh/macOS-Security-and-Privacy-Guide?tab=readme-ov-file#app-sandbox but I wrote those parts so I'm only plagiarizing myself. I also copied parts of official Apple documentation, didn't want to change them for the sake of accurate information. Wherever I do I link back to the source.

[netlify]

✅ Deploy Preview for privsec-dev ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	986f23d
🔍 Latest deploy log	https://app.netlify.com/sites/privsec-dev/deploys/6747bcc587c6420008f81443
😎 Deploy Preview	https://deploy-preview-270--privsec-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[ghost]

The reasoning needs work. This is not the reason for the attack surface

I can remove that part I guess. I'm not really aware of any other way it increases attack surface.

From https://support.apple.com/en-gb/guide/security/secebb113be1/web:

Just-in-time translation
In the just-in-time (JIT) translation pipeline, an x86_64 Mach object is identified early in the image execution path. When these images are encountered, the kernel transfers control to a special Rosetta translation stub rather than to the dynamic link editor, dyld(1). The translation stub then translates x86_64 pages during the image’s execution. This translation takes place entirely within the process. The kernel still verifies the code hashes of each x86_64 page against the code signature attached to the binary as the page is faulted in. In the event of a hash mismatch, the kernel enforces the remediation policy appropriate for that process.

Unsigned x86_64 code
A Mac with Apple silicon doesn’t permit native arm64 code to execute unless a valid signature is attached. This signature can be as simple as an ad hoc code signature (cf. codesign(1)) that doesn’t bear any actual identity from the secret half of an asymmetric key pair (it’s simply an unauthenticated measurement of the binary).
For binary compatibility, translated x86_64 code is permitted to execute through Rosetta with no signature information at all. No specific identity is conveyed to this code through the device-specific Secure Enclave signing procedure, and it executes with precisely the same limitations as native unsigned code executing on an Intel-based Mac.

[ghost]

Will it be recommended to use Safari or will the recommendation be to use a Chromium-based browser?

[friadev]

The reasoning needs work. This is not the reason for the attack surface

I can remove that part I guess. I'm not really aware of any other way it increases attack surface.

From https://support.apple.com/en-gb/guide/security/secebb113be1/web:

Just-in-time translation
In the just-in-time (JIT) translation pipeline, an x86_64 Mach object is identified early in the image execution path. When these images are encountered, the kernel transfers control to a special Rosetta translation stub rather than to the dynamic link editor, dyld(1). The translation stub then translates x86_64 pages during the image’s execution. This translation takes place entirely within the process. The kernel still verifies the code hashes of each x86_64 page against the code signature attached to the binary as the page is faulted in. In the event of a hash mismatch, the kernel enforces the remediation policy appropriate for that process.

Unsigned x86_64 code
A Mac with Apple silicon doesn’t permit native arm64 code to execute unless a valid signature is attached. This signature can be as simple as an ad hoc code signature (cf. codesign(1)) that doesn’t bear any actual identity from the secret half of an asymmetric key pair (it’s simply an unauthenticated measurement of the binary).
For binary compatibility, translated x86_64 code is permitted to execute through Rosetta with no signature information at all. No specific identity is conveyed to this code through the device-specific Secure Enclave signing procedure, and it executes with precisely the same limitations as native unsigned code executing on an Intel-based Mac.

I'm not sure how significant those are.

[friadev]

Will it be recommended to use Safari or will the recommendation be to use a Chromium-based browser?

I think just leave it up to the reader.

[nihil-admirari]

NIST offers configuration profiles and scripts for automatic configuration: https://github.com/usnistgov/macos_security/tree/sequoia. Can some of them be recommended?

[nihil-admirari]

1. LittleSnitch and LuLu block outgoing connections; built-in firewall – only incoming. There's no built-in replacement for these tools.
2. Latest version of LittleSnitch does cover DNS. With LuLu, it's possible to use dnscrypt-proxy locally.

[nihil-admirari]

macOS can be forced to clear FileVault keys from memory when hibernating by executing:

sudo pmset -a hibernatemode 25

and installing DestroyFVKeyOnStandby profile.

[nihil-admirari]

May be worth adding:

Compared to Linuxes, macOS doesn't sanitise $HOME when executing sudo: https://scriptingosx.com/2024/03/zsh-scripts-and-root-escalations/. It means that the entire content of shell init scripts is executed as root when elevating.

HOME can be removed from the following line in /etc/sudoers to mitigate it:

Defaults  env_keep += "HOME MAIL"

It may also be worthwhile to mark shell init scripts as immutable as the link suggests.