The database on the floor
CoreDuet's interaction database carries 644 permissions — world-readable in theory. In practice, the Data Vault gate does its job. I found the surface. I did not verify the compensating control.
There is a SQLite database on every macOS system that records what you do, when you do it, and how long you spend doing it. It underpins Siri Suggestions and Screen Time. It carries Unix permissions of 644 — readable by any process running as the same user. And yet it cannot, in practice, be read by any such process without authorisation. The Unix permissions are not the security boundary. This post is about what is, and about the cost of not checking that distinction before filing a report.
Situation
My first job in network infrastructure was at CityReach, one of the early internet hotels, in the mid-1990s. Those were the days when physical security was often much tighter than logical security — you could not get into the cage without a pass and a signature, but once you were inside, the shared NFS mounts were another matter entirely. One afternoon, working through a routine audit, I found a device configuration file sitting world-readable on a mount that half the floor could see. The file contained cleartext credentials. There was nothing stopping anyone from reading it; they simply had not thought to look.
The instinct that formed that day — check the permissions, then check whether the permissions are actually enforced — has never left me. Which makes what happened with this finding somewhat embarrassing in retrospect.
Investigation
CoreDuet is Apple's framework for recording user interaction data. Its backing store, interactionC.db, sits at ~/Library/Application Support/Knowledge/interactionC.db. The permissions, as reported by ls -la, are 644: owner read-write, group read, world read.
CoreDuet's interaction database at ~/Library/Application Support/Knowledge/interactionC.db carries permissions 644. The file contains structured SQLite data including application bundle IDs, usage timestamps, interaction categories, and activity metadata — the backing store for Siri Suggestions and Screen Time. An unprivileged process running as uid=501 can read the file without any entitlement check, exposing behavioural data about application usage and user activity patterns.
The file is genuinely interesting from a privacy standpoint. ZOBJECT records include bundle identifiers, timestamps, and categorical labels for user activities. If a process could read this freely, it would have a detailed log of application usage over time — the kind of data that analytics vendors pay handsomely for.
Finding
Apple closed the report: "No proof PoC was run or produced claimed output."
The reviewer was right to close it. On a SIP-enabled host — which is every production macOS system not in research or development use — the Data Vault compensating control at the kernel level blocks access to the Knowledge directory regardless of what the Unix permissions say. The 644 permissions are cosmetic on any system where SIP is intact. A process without the com.apple.private.corduroy.access entitlement, or without explicit TCC authorisation, cannot open the file. The sandbox and the Data Vault gate enforce this before the Unix permission check is ever reached.
The Data Vault restricts access to ~/Library/Application Support/Knowledge/ at the kernel level on SIP-enabled systems. Unix permissions of 644 are irrelevant because the kernel enforcement layer intervenes before they are consulted. The finding is only actionable on a SIP-disabled or jailbroken host — which falls outside Apple's threat model for this class of issue.
Implication
What I did was find the configuration file on the NFS mount. What I did not do was check whether the NFS mount was actually accessible from outside the cage. In this case, it was not. The compensating control held.
The lesson here is not subtle: identifying a surface is not the same as demonstrating exploitability. Verifying that a compensating control is absent — on the specific target, under the specific conditions — is not optional work that can be left to the reviewer. It is the work. A submission that says "the file has permissive Unix permissions and contains sensitive data" without demonstrating that those permissions are actually honoured on a production system is a submission that will be, and should be, closed for insufficient evidence.
On a SIP-disabled research VM or a jailbroken device, interactionC.db is readable without special entitlements. This is expected behaviour in those environments. It is not a vulnerability in those contexts — it is a research tool. The finding as submitted implied that this applied to production systems, which it does not.
In my view, Apple's threshold here is reasonable. The combination of Data Vault enforcement and TCC gating for the Knowledge directory represents a layered control that performs its intended function. The 644 permissions on the backing file are a historical artefact or an implementation detail, not a security gap.
Proof of concept
#!/bin/bash
# CoreDuet interaction database permission check
# Shows 644 permissions and demonstrates that Data Vault blocks
# access on SIP-enabled hosts.
# Own hardware only.
DB="$HOME/Library/Application Support/Knowledge/interactionC.db"
echo "=== File permissions ==="
ls -la "$DB" 2>/dev/null || echo "File not found"
echo ""
echo "=== SIP status ==="
csrutil status
echo ""
echo "=== Access attempt ==="
echo "On SIP-enabled host: Data Vault will deny access regardless of Unix permissions."
echo "On SIP-disabled research VM: access succeeds (expected, not a vulnerability)."
echo ""
sqlite3 "$DB" "SELECT count(*) FROM ZOBJECT LIMIT 1;" 2>&1 \
&& echo "Access succeeded (SIP likely disabled — research environment)" \
|| echo "Access denied (Data Vault active — expected on production system)"
echo ""
echo "=== Conclusion ==="
echo "644 permissions are cosmetic on SIP-enabled systems."
echo "Data Vault enforcement operates below the Unix permission layer."
echo "Apple's closure is correct: the compensating control is in place."Disclosure note
Disclosure
Finding CORE-01 was submitted to Apple Product Security via the Apple Security Research portal under the standard coordinated disclosure process.
Apple's closure reason: "No proof PoC was run or produced claimed output." Apple's reviewer correctly identified that the submission did not demonstrate unauthorised access on a SIP-enabled host, because the Data Vault compensating control prevents it.
In my view, Apple's closure is correct. The Data Vault gate does its job. This post is published as a record of the investigation, and specifically as an honest account of where the submission fell short.
All testing was performed on my own hardware.
Final thought
The configuration file on the NFS mount at CityReach was a real finding — the credentials were there, unprotected, readable by anyone who walked through the cage door. The lesson I took was to check permissions. The lesson I apparently did not fully absorb was to also check whether the door to the cage was actually unlocked. The database was on the floor. The floor was behind a gate I had not tested.
Are you there?