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.

[friadev]

Apple silicon Macs offer Rosetta 2, a translation layer that lets you run Intel apps on an ARM Mac. Since it allows you to run more software than you could otherwise run, installing Rosetta 2 increases your attack surface and should be avoided unless you absolutely need it.

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.

[duck09]

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.

[duck09]

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.