Files
Audiobuzz a46e5edf69 agent: add chrony supplementary group so it can read tracking.log (DAC)
The tracking.log read was still returning empty under enforcing with NO AVC —
the tell of a DAC (not SELinux) denial. Root cause: /var/log/chrony is mode
0750 chrony:chrony (others have no access), so the agent's DynamicUser (group
tss only) can't even traverse the directory to reach the 0644 tracking.log —
EACCES on open, which produces no audit record. Manager confirmed genuinely on
fleet-manager-1db3977 (chrony-capable), and uptime flowed while chrony didn't,
proving the agent was sending empty chrony (failed read), not a manager gap.
Earlier manual reads worked only as root (sudo) or because fleetadmin had been
usermod'd into chrony during the socket test (reverted on reboot — /etc/group
is on the volatile overlay).

Fix: SupplementaryGroups=tss chrony on the unit — the chrony group has r-x on
the 0750 dir so the agent can traverse it; the log file is world-readable. This
is the DAC half; the fleet_agent_chronylog SELinux module (02a6621) is the TE
half — BOTH are required (verified: group-only -> TE-denied; module-only ->
DAC-denied silently). Corrected the now-stale 'no group' code comment; recorded
the two-layer requirement in the .te and stig-deviations #16. Needs a
workstation image rebuild + reboot.
2026-07-10 12:45:44 +00:00

39 lines
2.1 KiB
Plaintext

# Raw module-policy syntax (compiled with `checkmodule -M -m`), NOT the refpolicy
# `policy_module()` m4 macro — that macro is only expanded by the refpolicy
# Makefile and checkmodule rejects it. See chrony-dhcp-dispatcher.te for the why.
module fleet_agent_chronylog 1.0.0;
########################################
# Let the fleet-agent READ chrony's tracking log under enforcing SELinux.
#
# fleet-agent (telemetry) reports clock health (source/stratum/offset) by reading
# /var/log/chrony/tracking.log (chronyd appends a line per clock update; enabled
# via `log tracking`). The agent runs as unconfined_service_t. chrony's log dir +
# files are labeled chronyd_var_log_t, and the shipped policy confines that type
# to chronyd_t + log-admin roles — so although the file is mode 0644, under
# enforcing the read is DENIED by type enforcement (DAC allows, TE does not).
# Verified 2026-07-10 on comet-beacon-54: with SELinux enforcing even a
# STIG-confined admin login (staff_t) gets "Permission denied" reading it, though
# a permissive-mode read succeeds — the tell-tale of a type-enforcement block.
#
# This grants ONLY read (open/read/getattr) on the chrony log type plus dir search
# to reach the file — no write, no other chrony access, and NO domain transition
# (the agent reads a file; it does not exec chronyc). This is the SELinux (TE)
# half; the DAC half is the `chrony` supplementary group in fleet-agent.service,
# needed to traverse the 0750 /var/log/chrony dir — BOTH are required to read the
# log. Minimal + auditable; justified in docs/stig-deviations.md #16. BENCH-VERIFY:
# the manager's Monitor chrony row populates on an enforcing boot; extend here only
# if a related chrony log AVC appears. Same policy-store-rebuild reproducibility
# caveat as #14/#15.
########################################
require {
type unconfined_service_t;
type chronyd_var_log_t;
class dir { search getattr open };
class file { open read getattr };
}
allow unconfined_service_t chronyd_var_log_t:dir { search getattr open };
allow unconfined_service_t chronyd_var_log_t:file { open read getattr };