T06 · System Persistence
- Location
references/cpu.md:95- Finding
Persistent CPU Governor Service Installed with System Privileges
- Content
View full analysis
/etc/systemd/system/cpu-performance.service << 'EOF' [Unit] Description=Set CPU governor to performance After=multi-user.target [Service] Type=oneshot ExecStart=/bin/bash -c "for f in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance > $f; done" RemainAfterExit=yes [Install] WantedBy=multi-user.target EOF systemctl enable --now cpu-performance.service ``` ### Technical Analysis The instructions create a root-owned systemd unit under `/etc/systemd/system` and enable it at boot. The service executes a shell command that writes to privileged CPU control interfaces for every CPU whenever the system starts. Although selecting the performance governor is related to performance tuning, permanently installing and enabling a system service is not necessary for diagnosis, profiling, or temporary benchmarking. It exceeds least privilege because the same evaluation can be performed using read-only inspection followed by a temporary governor change. The unit content is static in the current file, so there is no demonstrated hidden backdoor. Nevertheless, converting tuning advice into an automatically enabled privileged startup hook creates a dangerous execution boundary. If the unit content is altered before installation, the substituted command would run during startup with system privileges. ### Attack Path 1. A user or agent follows the CPU tuning instructions with root privileges. 2. The instructions overwrite `/etc/systemd/system/cpu-performance.service`. 3. `systemctl enable --now` starts the service and registers it for future boots. 4. The service writes to privileged sysfs CPU controls on every boot. 5. If an attacker can influence the generated unit content or command, the same startup hook can execute arbitr ...[truncated 558 chars]- Remediation
View remediation
