morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #4301] [Feature] Explain entitlements and derive static instrumentation constraints in inspect_signature #1707

New issue

Open

opened 2026-10-16 21:09:17 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:09:17 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4301

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Native analysis or decompilation

Current limitation

inspect_signature returns a Mach-O's entitlements as a raw dictionary and the hardened-runtime state as a Boolean. Before choosing a dynamic-analysis route, an analyst has to know what those entitlements mean and whether the signature already rules out a debugger, DYLD_INSERT_LIBRARIES, a foreign-team library or task-port-based instrumentation. That means reading Apple's entitlement pages one key at a time. This request asks REA to attach Apple's documented meaning to each extracted entitlement, report value types as observed, and derive a small set of static instrumentation constraints. Each fact names its basis and the host-policy inputs it cannot observe (System Integrity Protection, Developer Tools access, Developer Mode). Nothing is launched or attached.

Questions such as "will LLDB be able to attach to this hardened app?", "will dyld honor DYLD_INSERT_LIBRARIES here?", "can an unsigned dylib load into it?", "is it sandboxed, and with which exceptions?" and "does it opt in to Enhanced Security restrictions that crash in-process instrumentation?" are answered by entitlements, which REA extracts but does not interpret, and by CodeDirectory flags, of which the release build extracts only whether runtime is set (codesign.ts L115-L120).

Observations use REA 6.5.0 (npm rea-agents@6.5.0, tag rea-agents-6.5.0, commit 3b79af28e80785afce9f5998d8f03289402a1847) on macOS 27.0.1 (26A434) arm64 with Xcode 27.0 (27A266a).

Target	The release build reports	What an analyst needs to know
`codesign -s - -o runtime --entitlements ent.plist` with `com.apple.security.get-task-allow` and `com.apple.security.cs.disable-library-validation`	`hardened_runtime: true`, both keys as `true`	get-task-allow permits debugging on a SIP system; dyld still ignores `DYLD_*` variables (no `allow-dyld-environment-variables`); foreign-team libraries may load
`codesign -s - -o runtime` with no entitlements	`hardened_runtime: true`, `entitlements: null`	Apple: without get-task-allow, debugging is impossible on a system that uses SIP
stock `/System/Applications/Preview.app`	`com.apple.security.hardened-process.platform-restrictions: 2` and `...enhanced-security-version: 1`, both integers	Enhanced Security Mach IPC restrictions apply. Apple documents `enhanced-security-version` as a string, but this stock app carries an integer, so a type-assuming reader misreports it
stock `/System/Applications/Image Capture.app`	`com.apple.security.app-sandbox: false`	the key is present but disabled, so the app is not sandboxed by it

Current behavior, source-cited at the release tag:

The schema carries entitlements as an untyped JSON value and hardened_runtime as a nullable Boolean (nativeInspection.ts L146-L160). No code assigns meaning to any entitlement key.
The release's LLDB attach-denial remediation tells callers "see inspect_signature's debugger-attach facet" (LldbCallTracer.ts L165-L167), and the native investigation guide says the same (native-investigation.md L482-L485). Closed issue #3187 established that no such facet exists. Its fix on main (after 6.5.0) rewrote the guidance to point at hardened_runtime and the raw entitlements, adding no capability. Closed, unmerged PR #934 had implemented derived facets (debugger-attach, dyld-environment-variables, library-validation, executable-memory, app-sandbox) together with other signing-posture changes.

Use cases

No response

Desired outcome and success criteria

inspect_signature keeps its raw entitlements value unchanged and adds two derived, clearly labelled sections. Both are static: no process is launched, attached or injected.

Entitlement annotations. For each extracted entitlement:
- the category: hardened-runtime exception, debugging, App Sandbox, sandbox resource or exception, Enhanced Security (com.apple.security.hardened-process*), other documented, or unknown;
- Apple's documented one-line meaning and the documentation URL;
- the documented value type and default next to the observed type, with a type mismatch reported as observed (never coerced);
- whether the key is effective (true) or present but false;
- deprecation and its documented replacement (for example platform-restrictions replaced by platform-restrictions-string).
Unknown keys keep their raw value with category unknown. The macOS key com.apple.security.get-task-allow and the iOS-family key get-task-allow are distinguished.
App Sandbox summary. Sandboxed, not sandboxed, or unknown, plus the resource entitlements and temporary exceptions present, each with its documented meaning.
Instrumentation constraints. Each constraint is a fact with a state, the facts it used (CodeDirectory flags such as runtime, library-validation and restrict, the platform identifier, and specific entitlements), and the Apple statement relied on:
- task-port access, which debuggers and attach-mode instrumentation need;
- whether dyld honors DYLD_* environment variables;
- whether libraries signed by another team or unsigned may load;
- executable-memory posture (JIT, unsigned executable memory, disabled page protection);
- Enhanced Security Mach IPC restrictions that crash a process when it calls thread_set_state or uses certain exception-handler behaviors.
Constraint states. blocked by signature (a documented signature-level blocker is present), blocked if <host policy> (for example blocked when SIP is enabled), no signature blocker found, or unknown. There is no allowed state: host policy (SIP status, Developer Tools access or administrator authorization, Developer Mode on iOS-family devices) is never observed and is always listed as an unevaluated input. A combination that no cited Apple statement covers is unknown.
Scope of a fact. Facts are reported for the inspected executable only. A limitation notes that Apple applies these flags only to main executables and that libraries and plug-ins inherit the host's entitlements. When signing facts are unavailable or differ between slices, the affected facts are unknown.

Acceptance criteria

Fixture ent (clang output signed with codesign -f -s - -o runtime --entitlements ent.plist, where ent.plist sets com.apple.security.get-task-allow and com.apple.security.cs.disable-library-validation to true): both keys are annotated with their category and meaning. Task-port access is no signature blocker found. DYLD_* handling is blocked by signature (hardened runtime without com.apple.security.cs.allow-dyld-environment-variables). Foreign-team library loading is no signature blocker found.
Fixture hr (codesign -f -s - -o runtime, no entitlements): task-port access is blocked if SIP is enabled, with basis "hardened runtime without get-task-allow", and foreign-team library loading is blocked by signature (hardened-runtime library validation).
Fixture lvent (the ent signing plus -o runtime,library, so the CodeDirectory sets library-validation while the entitlements disable it): foreign-team library loading is unknown, naming both inputs, because no cited Apple statement says which one prevails.
Fixture uns (codesign --remove-signature): no fact reports allowed. Task-port access is no signature blocker found, and the SIP and Developer Tools inputs are listed as unevaluated.
Fixture unk (entitlements com.example.custom-flag true and com.apple.security.app-sandbox false): the custom key is unknown and kept; App Sandbox is not sandboxed with basis "key present with value false".
Stock /System/Applications/Preview.app on macOS 27.0.1: every com.apple.security.hardened-process* key is annotated. enhanced-security-version is reported with observed type integer against documented type string, and as deprecated. The Mach IPC restriction fact is present with basis platform-restrictions 2.
Stock /System/Applications/Image Capture.app: App Sandbox is not sandboxed (present, false).
For every target above, the existing entitlements and hardened_runtime values are byte-for-byte unchanged, and provenance lists only signature-display commands.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Affected area

inspect_signature (MCP) and rea inspect-signature (CLI): the result schema, a documented entitlement catalog (keys, categories, types, defaults, meanings, URLs), constraint derivation, the LLDB attach-denial remediation and native investigation guide, which can then point at a real field, and tests on self-built and stock targets.

Non-goals

Launching, attaching to, or injecting into any process, or confirming these constraints at run time. Contribution scope requires a separate maintainer decision for that.
Bypassing, disabling or working around any protection (SIP, library validation, hardened runtime, sandbox). Detecting and explaining a protection is in scope; defeating it is not.
Decoding and reporting the CodeDirectory posture itself (version, flags, slots, requirements); this request consumes the flags and platform identifier that the blocking request below adds. Launch and library constraints and provisioning-profile allowlists are requested separately.
Per-slice reporting for universal files (open PR #3583).
Reading the host's SIP, Developer Tools or Developer Mode state.

Verification available so far

I can suggest a sample or manual check

Verification details (optional)

No response

Alternatives considered

Documentation only (the #3187 fix). Pointing at hardened_runtime and raw entitlements is accurate, but every caller must still apply Apple's entitlement semantics itself, including cases such as a present app-sandbox: false or an integer where Apple documents a string.
A single debugger-attach: allowed/blocked verdict, as in #934. This is simpler, but it hides the host-policy inputs that decide the outcome. The states above keep those inputs explicit.

Possible direction

No response

References

Depends on:

Report CodeDirectory posture and the full requirement set in inspect_signature (#4298): the constraints need the decoded CodeDirectory flags library-validation and restrict, the other flags codesign prints, and the platform identifier, which the release build does not extract and that request adds.

Apple documentation:

Hardened Runtime: "The Hardened Runtime, along with System Integrity Protection (SIP), protects the runtime integrity of your software by preventing certain classes of exploits, like code injection, dynamically linked library (DLL) hijacking, and process memory space tampering." On the scope of entitlements: "Shared libraries, frameworks, and in-process plug-ins inherit the entitlements of their host executable."
Debugging Tool Entitlement: debuggers can "retrieve a valid task port for unsigned and third-party apps with the Get task allow entitlement set to true. However, even with the debugging tool entitlement, a debugger can't get the task ports of processes that don't have the Get task allow entitlement, and that are therefore protected by System Integrity Protection."
Resolving common notarization issues: com.apple.security.get-task-allow "facilitates debugging on a system that uses System Integrity Protection (SIP) by circumventing certain security checks"; removing it "makes it impossible to debug the binary on a system that uses System Integrity Protection." A plug-in host "can include the com.apple.security.get-task-allow entitlement if it also includes the Disable Library Validation Entitlement."
Allow DYLD environment variables entitlement: it "causes the macOS dynamic linker (dyld) to read from environment variables that begin with DYLD_", and "you also need the Disable Library Validation Entitlement if an injected library isn't signed with the expected team ID."
Disable Library Validation Entitlement: "The Hardened Runtime enables library validation by default. This security-hardening feature prevents a program from loading frameworks, plug-ins, or libraries unless they're either signed by Apple or signed with the same Team ID as the main executable."
Allow execution of JIT-compiled code entitlement, Allow Unsigned Executable Memory Entitlement and Disable Executable Memory Protection Entitlement. The last "effectively encompasses the behavior provided by the Allow Unsigned Executable Memory Entitlement, but not the Disable Library Validation Entitlement."
App Sandbox Entitlement: "A Boolean value that indicates whether the app may use access control technology to contain damage to the system and user data if an app is compromised."
Enhanced Security: com.apple.security.hardened-process (Boolean, default true, macOS 26.0+); platform-restrictions (integer, deprecated, replaced by platform-restrictions-string, a string, macOS 26.4+); enhanced-security-version ("Type: string", deprecated). Conforming to Mach IPC security restrictions: with platform-restrictions "with a value of at least 1 and the system detects a potentially insecure use of Mach IPC, the system crashes your process", including when the process "calls thread_set_state on one of its threads".
isLibraryValidationRequired and isDynamicLinkerPolicyHardened: each flag "only has effect on main executables".
TN3125: Inside Code Signing: Provisioning Profiles: "On other Apple platforms the equivalent to com.apple.security.get-task-allow is get-task-allow".
REA scope (CONTRIBUTING.md, "Contribution scope"): "Static protection detection is distinct from defeating that protection." Launching or attaching to a process, injecting instrumentation, running scripts, and changing memory or registers "require review of target selection, execution and mutation authority, provenance, resource limits, cancellation, and cleanup."

The mapping from task-port access to attach-mode tools such as Frida is general knowledge, not established by the Apple pages cited. The proposed facts are stated in Apple's terms for that reason.

Originally created by @coygeek on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4301 ### Before submitting - [X] I searched the open and closed issues and pull requests for a related proposal. - [X] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [X] This request does not include credentials, private samples, or sensitive target data. ### Area Native analysis or decompilation ### Current limitation `inspect_signature` returns a Mach-O's entitlements as a raw dictionary and the hardened-runtime state as a Boolean. Before choosing a dynamic-analysis route, an analyst has to know what those entitlements mean and whether the signature already rules out a debugger, `DYLD_INSERT_LIBRARIES`, a foreign-team library or task-port-based instrumentation. That means reading Apple's entitlement pages one key at a time. This request asks REA to attach Apple's documented meaning to each extracted entitlement, report value types as observed, and derive a small set of static instrumentation constraints. Each fact names its basis and the host-policy inputs it cannot observe (System Integrity Protection, Developer Tools access, Developer Mode). Nothing is launched or attached. Questions such as "will LLDB be able to attach to this hardened app?", "will dyld honor `DYLD_INSERT_LIBRARIES` here?", "can an unsigned dylib load into it?", "is it sandboxed, and with which exceptions?" and "does it opt in to Enhanced Security restrictions that crash in-process instrumentation?" are answered by entitlements, which REA extracts but does not interpret, and by CodeDirectory flags, of which the release build extracts only whether `runtime` is set ([codesign.ts L115-L120](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/native/parsers/codesign.ts#L115-L120)). Observations use REA 6.5.0 (npm `rea-agents@6.5.0`, tag `rea-agents-6.5.0`, commit `3b79af28e80785afce9f5998d8f03289402a1847`) on macOS 27.0.1 (26A434) arm64 with Xcode 27.0 (27A266a). | Target | The release build reports | What an analyst needs to know | | --- | --- | --- | | `codesign -s - -o runtime --entitlements ent.plist` with `com.apple.security.get-task-allow` and `com.apple.security.cs.disable-library-validation` | `hardened_runtime: true`, both keys as `true` | get-task-allow permits debugging on a SIP system; dyld still ignores `DYLD_*` variables (no `allow-dyld-environment-variables`); foreign-team libraries may load | | `codesign -s - -o runtime` with no entitlements | `hardened_runtime: true`, `entitlements: null` | Apple: without get-task-allow, debugging is impossible on a system that uses SIP | | stock `/System/Applications/Preview.app` | `com.apple.security.hardened-process.platform-restrictions: 2` and `...enhanced-security-version: 1`, both integers | Enhanced Security Mach IPC restrictions apply. Apple documents `enhanced-security-version` as a string, but this stock app carries an integer, so a type-assuming reader misreports it | | stock `/System/Applications/Image Capture.app` | `com.apple.security.app-sandbox: false` | the key is present but disabled, so the app is not sandboxed by it | Current behavior, source-cited at the release tag: - The schema carries `entitlements` as an untyped JSON value and `hardened_runtime` as a nullable Boolean ([nativeInspection.ts L146-L160](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/domain/native/nativeInspection.ts#L146-L160)). No code assigns meaning to any entitlement key. - The release's LLDB attach-denial remediation tells callers "see inspect_signature's debugger-attach facet" ([LldbCallTracer.ts L165-L167](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/native/LldbCallTracer.ts#L165-L167)), and the native investigation guide says the same ([native-investigation.md L482-L485](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/docs/native-investigation.md#L482-L485)). Closed issue #3187 established that no such facet exists. Its fix on main (after 6.5.0) rewrote the guidance to point at `hardened_runtime` and the raw `entitlements`, adding no capability. Closed, unmerged PR #934 had implemented derived facets (`debugger-attach`, `dyld-environment-variables`, `library-validation`, `executable-memory`, `app-sandbox`) together with other signing-posture changes. ### Use cases _No response_ ### Desired outcome and success criteria `inspect_signature` keeps its raw `entitlements` value unchanged and adds two derived, clearly labelled sections. Both are static: no process is launched, attached or injected. - **Entitlement annotations.** For each extracted entitlement: - the category: hardened-runtime exception, debugging, App Sandbox, sandbox resource or exception, Enhanced Security (`com.apple.security.hardened-process*`), other documented, or unknown; - Apple's documented one-line meaning and the documentation URL; - the documented value type and default next to the observed type, with a type mismatch reported as observed (never coerced); - whether the key is effective (`true`) or present but `false`; - deprecation and its documented replacement (for example `platform-restrictions` replaced by `platform-restrictions-string`). Unknown keys keep their raw value with category `unknown`. The macOS key `com.apple.security.get-task-allow` and the iOS-family key `get-task-allow` are distinguished. - **App Sandbox summary.** Sandboxed, not sandboxed, or unknown, plus the resource entitlements and temporary exceptions present, each with its documented meaning. - **Instrumentation constraints.** Each constraint is a fact with a state, the facts it used (CodeDirectory flags such as `runtime`, `library-validation` and `restrict`, the platform identifier, and specific entitlements), and the Apple statement relied on: - task-port access, which debuggers and attach-mode instrumentation need; - whether dyld honors `DYLD_*` environment variables; - whether libraries signed by another team or unsigned may load; - executable-memory posture (JIT, unsigned executable memory, disabled page protection); - Enhanced Security Mach IPC restrictions that crash a process when it calls `thread_set_state` or uses certain exception-handler behaviors. - **Constraint states.** `blocked by signature` (a documented signature-level blocker is present), `blocked if <host policy>` (for example blocked when SIP is enabled), `no signature blocker found`, or `unknown`. There is no `allowed` state: host policy (SIP status, Developer Tools access or administrator authorization, Developer Mode on iOS-family devices) is never observed and is always listed as an unevaluated input. A combination that no cited Apple statement covers is `unknown`. - **Scope of a fact.** Facts are reported for the inspected executable only. A limitation notes that Apple applies these flags only to main executables and that libraries and plug-ins inherit the host's entitlements. When signing facts are unavailable or differ between slices, the affected facts are `unknown`. **Acceptance criteria** - [ ] Fixture `ent` (`clang` output signed with `codesign -f -s - -o runtime --entitlements ent.plist`, where `ent.plist` sets `com.apple.security.get-task-allow` and `com.apple.security.cs.disable-library-validation` to `true`): both keys are annotated with their category and meaning. Task-port access is `no signature blocker found`. `DYLD_*` handling is `blocked by signature` (hardened runtime without `com.apple.security.cs.allow-dyld-environment-variables`). Foreign-team library loading is `no signature blocker found`. - [ ] Fixture `hr` (`codesign -f -s - -o runtime`, no entitlements): task-port access is `blocked if SIP is enabled`, with basis "hardened runtime without get-task-allow", and foreign-team library loading is `blocked by signature` (hardened-runtime library validation). - [ ] Fixture `lvent` (the `ent` signing plus `-o runtime,library`, so the CodeDirectory sets `library-validation` while the entitlements disable it): foreign-team library loading is `unknown`, naming both inputs, because no cited Apple statement says which one prevails. - [ ] Fixture `uns` (`codesign --remove-signature`): no fact reports `allowed`. Task-port access is `no signature blocker found`, and the SIP and Developer Tools inputs are listed as unevaluated. - [ ] Fixture `unk` (entitlements `com.example.custom-flag` `true` and `com.apple.security.app-sandbox` `false`): the custom key is `unknown` and kept; App Sandbox is `not sandboxed` with basis "key present with value false". - [ ] Stock `/System/Applications/Preview.app` on macOS 27.0.1: every `com.apple.security.hardened-process*` key is annotated. `enhanced-security-version` is reported with observed type integer against documented type string, and as deprecated. The Mach IPC restriction fact is present with basis `platform-restrictions` `2`. - [ ] Stock `/System/Applications/Image Capture.app`: App Sandbox is `not sandboxed` (present, `false`). - [ ] For every target above, the existing `entitlements` and `hardened_runtime` values are byte-for-byte unchanged, and provenance lists only signature-display commands. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) **Affected area** `inspect_signature` (MCP) and `rea inspect-signature` (CLI): the result schema, a documented entitlement catalog (keys, categories, types, defaults, meanings, URLs), constraint derivation, the LLDB attach-denial remediation and native investigation guide, which can then point at a real field, and tests on self-built and stock targets. **Non-goals** - Launching, attaching to, or injecting into any process, or confirming these constraints at run time. Contribution scope requires a separate maintainer decision for that. - Bypassing, disabling or working around any protection (SIP, library validation, hardened runtime, sandbox). Detecting and explaining a protection is in scope; defeating it is not. - Decoding and reporting the CodeDirectory posture itself (version, flags, slots, requirements); this request consumes the flags and platform identifier that the blocking request below adds. Launch and library constraints and provisioning-profile allowlists are requested separately. - Per-slice reporting for universal files (open PR #3583). - Reading the host's SIP, Developer Tools or Developer Mode state. ### Verification available so far I can suggest a sample or manual check ### Verification details (optional) _No response_ ### Alternatives considered - **Documentation only (the #3187 fix).** Pointing at `hardened_runtime` and raw `entitlements` is accurate, but every caller must still apply Apple's entitlement semantics itself, including cases such as a present `app-sandbox: false` or an integer where Apple documents a string. - **A single `debugger-attach: allowed/blocked` verdict, as in #934.** This is simpler, but it hides the host-policy inputs that decide the outcome. The states above keep those inputs explicit. ### Possible direction _No response_ ### References Depends on: - `Report CodeDirectory posture and the full requirement set in inspect_signature` (#4298): the constraints need the decoded CodeDirectory flags `library-validation` and `restrict`, the other flags codesign prints, and the platform identifier, which the release build does not extract and that request adds. Apple documentation: - [Hardened Runtime](https://developer.apple.com/documentation/security/hardened-runtime): "The Hardened Runtime, along with System Integrity Protection (SIP), protects the runtime integrity of your software by preventing certain classes of exploits, like code injection, dynamically linked library (DLL) hijacking, and process memory space tampering." On the scope of entitlements: "Shared libraries, frameworks, and in-process plug-ins inherit the entitlements of their host executable." - [Debugging Tool Entitlement](https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.cs.debugger): debuggers can "retrieve a valid task port for unsigned and third-party apps with the `Get task allow` entitlement set to `true`. However, even with the debugging tool entitlement, a debugger can't get the task ports of processes that don't have the `Get task allow` entitlement, and that are therefore protected by System Integrity Protection." - [Resolving common notarization issues](https://developer.apple.com/documentation/security/resolving-common-notarization-issues): `com.apple.security.get-task-allow` "facilitates debugging on a system that uses System Integrity Protection (SIP) by circumventing certain security checks"; removing it "makes it impossible to debug the binary on a system that uses System Integrity Protection." A plug-in host "can include the `com.apple.security.get-task-allow` entitlement if it also includes the Disable Library Validation Entitlement." - [Allow DYLD environment variables entitlement](https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.cs.allow-dyld-environment-variables): it "causes the macOS dynamic linker (`dyld`) to read from environment variables that begin with `DYLD_`", and "you also need the Disable Library Validation Entitlement if an injected library isn't signed with the expected team ID." - [Disable Library Validation Entitlement](https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.cs.disable-library-validation): "The Hardened Runtime enables library validation by default. This security-hardening feature prevents a program from loading frameworks, plug-ins, or libraries unless they're either signed by Apple or signed with the same Team ID as the main executable." - [Allow execution of JIT-compiled code entitlement](https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.cs.allow-jit), [Allow Unsigned Executable Memory Entitlement](https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.cs.allow-unsigned-executable-memory) and [Disable Executable Memory Protection Entitlement](https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.cs.disable-executable-page-protection). The last "effectively encompasses the behavior provided by the Allow Unsigned Executable Memory Entitlement, but not the Disable Library Validation Entitlement." - [App Sandbox Entitlement](https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.app-sandbox): "A Boolean value that indicates whether the app may use access control technology to contain damage to the system and user data if an app is compromised." - Enhanced Security: [com.apple.security.hardened-process](https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.hardened-process) (Boolean, default `true`, macOS 26.0+); [platform-restrictions](https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.hardened-process.platform-restrictions) (integer, deprecated, replaced by [platform-restrictions-string](https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.hardened-process.platform-restrictions-string), a string, macOS 26.4+); [enhanced-security-version](https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.hardened-process.enhanced-security-version) ("Type: string", deprecated). [Conforming to Mach IPC security restrictions](https://developer.apple.com/documentation/xcode/conforming-to-mach-ipc-security-restrictions): with `platform-restrictions` "with a value of at least `1` and the system detects a potentially insecure use of Mach IPC, the system crashes your process", including when the process "calls `thread_set_state` on one of its threads". - [isLibraryValidationRequired](https://developer.apple.com/documentation/lightweightcoderequirements/ondiskcodesigningflags/valueset/islibraryvalidationrequired) and [isDynamicLinkerPolicyHardened](https://developer.apple.com/documentation/lightweightcoderequirements/ondiskcodesigningflags/valueset/isdynamiclinkerpolicyhardened): each flag "only has effect on main executables". - [TN3125: Inside Code Signing: Provisioning Profiles](https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles): "On other Apple platforms the equivalent to `com.apple.security.get-task-allow` is `get-task-allow`". - REA scope (`CONTRIBUTING.md`, "Contribution scope"): "Static protection detection is distinct from defeating that protection." Launching or attaching to a process, injecting instrumentation, running scripts, and changing memory or registers "require review of target selection, execution and mutation authority, provenance, resource limits, cancellation, and cleanup." The mapping from task-port access to attach-mode tools such as Frida is general knowledge, not established by the Apple pages cited. The proposed facts are stated in Apple's terms for that reason.

bsakaguchi referenced this issue

2026-10-31 00:54:51 +00:00

[PR #1707] [MERGED] perf(domain): avoid duplicate readiness bundle validation #4769

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#1707

No description provided.

Rows
Columns