rc.local is a Unix and Linux startup script that runs late in the boot process. Administrators use it to execute local commands once the system reaches multi-user mode, although modern init systems often replace or ignore it. Because it can launch commands with high privileges, its contents affect system control and startup security.
What rc.local Does at Boot Time
rc.local is a late-boot hook, so it sits near the end of system startup rather than at the beginning. That timing matters because commands placed there run after many core services are already active, which makes it a convenient but powerful place to apply final host-specific actions.
Historically, administrators used it for one-off local startup commands, quick environment fixes, or legacy scripts that were easier to keep outside a formal init unit. In modern Linux environments, though, its behaviour depends on the init system and distribution policy, so it is often ignored, disabled, or kept only for compatibility.
Why rc.local Is Security-Relevant
Because rc.local can run commands with elevated privileges during boot, it affects system control before normal user activity begins. Anything executed there can change network settings, start background processes, alter file permissions, or load persistence logic that is harder to notice than an interactive login action.
The security significance is less about the file itself and more about the trust placed in a script that executes automatically on every start. If that trust is misplaced, the host may launch unsafe commands before monitoring, hardening, or local inspection has fully started.
Common Operational Uses and Trade-offs
Administrators sometimes keep rc.local because it is simple and familiar, especially on older systems or in environments with accumulated operational shortcuts. It can be useful for bridging gaps during migration, but it is not a strong substitute for a managed startup service, configuration management, or documented boot orchestration.
The trade-off is maintainability. A hidden shell script can become an undocumented control point, and over time it may outlive the service it was meant to replace. That makes troubleshooting harder and increases the chance that critical startup behaviour is preserved only in a file few people review.
How rc.local Affects Hardening and Review
From a defensive perspective, rc.local should be treated as part of the host startup trust boundary. Reviewers should know whether it exists, whether the init system still honours it, what commands it launches, and whether those commands are still required. A late-boot script that is never reviewed can become a quiet place for unwanted persistence or risky administrative shortcuts.
When modern service managers are in use, the more robust pattern is to express startup logic through managed units, logging, and explicit ownership rather than a legacy compatibility hook. That makes execution order, failure handling, and access review much easier to govern.
Risk and Threat Considerations
rc.local is risky when organisations assume it is harmless legacy glue rather than an active privilege-bearing execution path. If an attacker or careless operator can modify it, the script can become an easy persistence point or an unchecked way to run commands during boot with high privileges.
Failure mechanism: The host executes an unreviewed or tampered startup script early enough that malicious or unsafe actions run before the system is fully observed or manually checked.
Impact: This can lead to persistent compromise, unauthorized system changes, hidden service startup, or repeated execution of attacker-controlled commands on every reboot.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | rc.local can launch privileged startup commands that require controlled access |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | rc.local can bypass standard startup management if left unmanaged | |
| Recommendation — Review privileged startup scripts and remove unnecessary execution paths. Harden hosts by replacing ad hoc boot scripts with controlled startup configuration. | ||
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | rc.local is a host startup configuration that affects system control and hardening |
| CM-7 — Least Functionality | Legacy rc.local usage can preserve unnecessary commands at boot | |
| Recommendation — Standardize and review boot-time configuration so startup behavior is documented and authorized. Disable unused startup hooks and keep only required boot commands active. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | rc.local is part of system configuration that must be controlled and reviewed |
| Recommendation — Track and approve boot scripts as managed configuration items. | ||
Practitioner Guidance
What to watch for: Treat rc.local as a migration and exception-control item, not a convenience default. If it still exists, confirm who owns it, whether the commands are still necessary, and whether another startup mechanism now provides the same function more cleanly.
Governance implication: Keep its contents under the same change control and review discipline as other privileged boot-time configuration, because a small script in the boot path can have system-wide effects.
Related resources from NHI Mgmt Group
- Why are local .env files and config notes risky in Microsoft 365?
- How should teams respond to a local Linux privilege escalation flaw in shared environments?
- What is the difference between global identity strategy and local governance?
- How should security teams handle local accounts in cloud and SaaS apps?