Linux access audit with SQL

The access test, before and after

I collected file modes, used a SQL policy join to identify unsafe access, applied the two matched fixes and repeated the same checks. A separate process running as UID/GID 65534 with no supplementary groups tested actual file opens.

All three file-content hashes remained unchanged. The script was never executed and the write probe opened it without truncating or writing bytes.

From Linux modes to a SQL finding

Python inventories the three root-owned files using lstat. SQLite stores the measured modes as integers and joins them to a policy table by path. The bitwise predicate selects a file when any forbidden permission bit is present.

SELECT a.path, a.mode, p.forbidden_mask,
       p.target_mode, p.risk
FROM assets AS a
JOIN policies AS p ON p.path = a.path
WHERE (a.mode & p.forbidden_mask) != 0
ORDER BY a.path;

The secret policy forbids group/other read (0044). The script and notice policies forbid group/other write (0022). Octal modes are converted to integers before insertion; values enter SQLite through parameterized statements.

Only the matched paths receive their declared target modes. The second SQL pass returns zero findings under the same policies. The child-process tests then establish that the access change was enforced on this Linux runner.

The remediation decision

Restrict the secret to its owner. Its dummy token illustrates a confidentiality risk: another local user could open a file intended for the service owner. The 0600 target preserves owner read/write and removes group/other access.

Remove shared write access from the script. A script writable by other users creates an integrity risk if a trusted process later executes it. That later execution is a risk scenario, not an observed event here. The 0755 target keeps owner write and public read/execute while removing group/other write.

Retest the intended access too. The public notice must remain readable. Keeping that control prevents a blanket lock-down from appearing to be a successful fix. On a real system, I would confirm the service identity and required access with its owner before changing modes.

Recorded execution

The retained run used Ubuntu 24.04.5, Python 3.11.17 and SQLite 3.45.1 at 13:43 UTC on 26 October 2026. All eight tests passed, including the actual unprivileged access test. The JSON records the source hashes, execution timestamp and CI context.

PASS: 2 permission findings -> 0 under the same SQL policies
UID 65534: secret read allowed -> denied; script write allowed -> denied
Control: public read allowed -> allowed; file contents unchanged; parent UID remains 0
Scope: isolated Linux dummy files; no production system, account or service changed

Reproduce the lab and inspect execution provenance ↗