What supported public API and verification contract should a sandboxed macOS file manager use to preserve a copied file's quarantine/provenance metadata? We observe different results in App Sandbox versus Finder and an otherwise-matched non-sandbox diagnostic. We want to keep App Sandbox and all security protections enabled, not remove quarantine or invent undocumented flag masks.
Environment: macOS 26.6.2 (25G83), Apple Silicon, local APFS. Optimized Foundation-only diagnostic, Apple Development signing, Hardened Runtime, launched directly as an executable. The sandbox variant has app-sandbox, user-selected read/write and app-scope bookmark entitlements. This is not a notarized distribution-build comparison.
Reproduction:
- Use an existing regular JPEG with naturally present com.apple.quarantine metadata identifying Chrome, raw flags 0283 and a nonempty event field. Keep the original read-only. Record SHA-256, length, full raw extended attributes and fresh NSURL quarantinePropertiesKey observations.
- Keep access to a user-granted local test directory active. Copy to a new, absent destination in a fresh directory using each of these three arms:
- fclonefileat with CLONE_ACL | CLONE_NOFOLLOW_ANY | CLONE_RESOLVE_BENEATH (28).
- copyfile with COPYFILE_CLONE | COPYFILE_ACL; record COPYFILE_STATE_WAS_CLONED.
- FileManager.copyItem(at:to:).
- Observe source and destination without setting, removing or repairing metadata. Each arm waits at least 1.1 seconds before copying; the source quarantine timestamp is much older than call time.
- Repeat with fresh destinations. Also copy the same source through actual Finder Copy/Paste twice.
- Compare two signed variants made from the same compiled payload, with identical executable name, bundle ID, Development identity and Hardened Runtime. The only signed entitlement difference is app-sandbox=true versus its omission. The sandbox variant resolves the existing exact folder grant; the non-sandbox diagnostic uses that same fixed test directory directly.
Results:
- Sandbox diagnostic: all six calls succeed and data hashes/lengths match. All six outputs change raw flags 0283 to 0082, agent Chrome to the diagnostic app, event field nonempty to empty, and timestamp. Public output lacks the source event identifier and adds LSQuarantineTypeSandboxed.
- Matched non-sandbox diagnostic: all six copies preserve the full observed raw quarantine record and public quarantine dictionary. copyfile reports WAS_CLONED=true in both contexts.
- Finder: both copies preserve the full observed raw quarantine record and public dictionary.
- Source bytes and declared preserved metadata remain unchanged. Other compared raw attributes, mode, flags, birth/modification times, owner/group and ACL match in these cases.
We also reproduced timestamp-only differences with files naturally quarantined by the diagnostic itself. The foreign-agent control above shows that the difference is not limited to timestamp. The chosen source exposes no public origin/data URL, so their preservation is untested. We have not traced the responsible internal component, tested Gatekeeper effects, or established whether the transformation is security-equivalent. We do not claim the three APIs use independent implementations or that all possible public API combinations have been tested.
Could you clarify:
- Is this transformation expected for copying from an App Sandbox process, or should we file it as a bug? What documented preservation behavior should a sandboxed file manager rely on?
- Is there a supported API or operation that preserves the source's quarantine/provenance metadata in this context without disabling App Sandbox or weakening security protections?
- If exact raw equality is intentionally not guaranteed, which supported public properties or behaviors should verification check? Is a quarantine-properties dictionary round-trip supported, and what information does it preserve or omit? We have not attempted a metadata repair.
Separately, a pathname-based repair after cloning would require its own destination-identity/race safety review because the clone call does not return a creation-bound destination descriptor. We are asking for supported API semantics, not private implementation details or a security bypass.
We can prepare a minimal sanitized standalone reproducer if needed. No user files, sandbox grants, private logs or diagnostic binaries are attached to this initial question.
- Is this transformation expected for copying from an App Sandbox process, or should we file it as a bug? What documented preservation behavior should a sandboxed file manager rely on?
It's the expected default behavior, but not necessarily appropriate for all situations.
- Is there a supported API or operation that preserves the source's quarantine/provenance metadata in this context without disabling App Sandbox or weakening security protections?
So, I believe the entitlement "com.apple.security.files.user-selected.executable" is what you need to add. It's normally described in the context of apps that generate true executable files, but I think there's a reasonable argument that it’s also appropriate for dedicated file management apps.
- If exact raw equality is intentionally not guaranteed, which supported public properties or behaviors should verification check? Is a quarantine-properties dictionary round-trip supported, and what information does it preserve or omit? We have not attempted a metadata repair.
My recollection is that "com.apple.security.files.user-selected.executable" means your app has full access to the quarantine attribute, so you'd preserve or remove it as needed.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
