Opening Framing: The Computer You Don't See Is the Computer That Matters
In Week 5, we examined memory and isolation — how the operating system creates boundaries that allow multiple processes to coexist without interference. But we focused on processes that you start: applications you launch, commands you run, programs you consciously invoke.
This week confronts a deeper reality: most of what your computer does happens without you. Before you log in, while you sleep, and after you log out, the system is busy. Services start. Daemons listen. Background processes enforce rules, maintain state, and make decisions on your behalf — whether you asked them to or not.
Real systems do not run because of users. They run in spite of them. The always-on layer of services and daemons is where the system's true authority lives.
A modern operating system is governed not by users, but by long-running background services that enforce trust, availability, and control.
Mental Model: The City That Never Sleeps
Think of an operating system as a city. Users are the people who walk the streets, visit shops, and go about their daily business. But the city doesn't stop when the people go home.
- Power plants run continuously, providing electricity regardless of who's awake
- Water treatment operates around the clock, maintaining pressure and purity
- Traffic systems manage flow even at 3 AM when streets are empty
- Emergency services remain ready, waiting for calls that may never come
- Security patrols watch buildings whether or not anyone is inside
Services and daemons are the infrastructure of your operating system. They are the power plants, traffic controllers, and security patrols. If one is compromised, the entire city is at risk — not because citizens made a mistake, but because the infrastructure they depend on was subverted.
Mental model: services are the invisible infrastructure that makes everything else possible. Compromise the infrastructure, and you compromise everything built on top of it.
1) What Is a System Service?
A system service is a program that provides foundational capability to other programs or to the system itself. Unlike applications that respond to user commands, services exist to serve other software, the operating system, or the network.
Services handle responsibilities that must be available continuously:
- Authentication services verify identity when users log in
- Logging services record events for later analysis
- Network services manage connections, DNS resolution, and routing
- Time services synchronize clocks across systems
- Print services queue and manage document printing
- Update services check for and apply system patches
The critical insight is that services are not optional conveniences. Many system functions simply do not work without their supporting services. If the DNS service fails, name resolution stops. If the authentication service fails, no one can log in. Services are the hidden dependencies that make visible functionality possible.
Key insight: services exist to serve other software, not users directly. This is why their compromise is often invisible — users don't interact with them consciously.
2) What Is a Daemon?
The term "daemon" comes from Unix tradition and refers to a specific type of service: a background process that starts early in the boot sequence, runs continuously, and typically operates with elevated privileges.
Daemons have distinctive characteristics:
- Detached from terminals: they don't need a user session to run
- Parent process is init/systemd: they are adopted by the system's first process
- Long-running: designed to run from boot until shutdown
- Often privileged: many run as root or SYSTEM to access protected resources
- Named with 'd' suffix: sshd, httpd, systemd, crond (convention, not rule)
In Windows, the equivalent concept is a Windows Service. The implementation differs, but the security implications are identical: these are programs that run with authority, continuously, without user oversight.
Consider sshd, the SSH daemon. It runs constantly, listening for network connections, ready to authenticate users and grant them shell access. It must run as root because it needs to spawn processes as different users. If sshd is compromised, an attacker gains the ability to authenticate anyone, or no one, as they choose.
Key insight: daemons often have the highest privileges on the system because they need to serve multiple users and access protected resources.
3) Background Trust: The Delegation You Didn't Know You Made
Every time you use a computer, you implicitly trust that dozens of services are behaving correctly. You trust that:
- The authentication service correctly validates passwords
- The logging service accurately records events
- The network service routes traffic to the right destinations
- The update service installs legitimate patches
- The time service provides accurate timestamps
This is background trust — the implicit delegation of critical functions to software you probably cannot name, written by people you will never meet, configured by defaults you likely never examined.
Background trust is not inherently bad. Modern computing would be impossible without it. But it creates a security dynamic that users rarely appreciate: the services they trust most are the services they think about least.
When security professionals talk about "trusted computing base" (TCB), they mean exactly this: the set of components that must be trustworthy for the system's security claims to hold. Services and daemons form a large portion of any system's TCB.
Key insight: background trust is the assumption that invisible components behave correctly. Attackers exploit this by targeting what users don't watch.
4) Why Attackers Target Services
From an attacker's perspective, compromising a service is far more valuable than compromising a user application. Here's why:
- Authority: Services often run with elevated privileges (root, SYSTEM). Compromising a privileged service grants the attacker those same privileges.
- Persistence: Services restart automatically. Malicious code in a service survives reboots without additional persistence mechanisms.
- Invisibility: Users don't monitor services. A compromised service can operate for months without detection.
- Legitimacy: Service traffic looks normal. Network connections from httpd or sshd don't trigger the same suspicion as unknown executables.
- Reach: Network-facing services can be attacked remotely. No phishing required — just send malicious input to the listening port.
Consider the security implications: if an attacker can inject code into a service that runs as root, starts at boot, handles network traffic, and is expected to run continuously, they have achieved near-perfect compromise. They have authority, persistence, stealth, and remote access — all from a single foothold.
This is why service hardening is not optional. Every unnecessary service is attack surface. Every over-privileged service is an escalation path. Every unmonitored service is a hiding place.
5) Boot-Time Security: Before Users Exist
One of the most important security concepts in this unit is understanding that security decisions begin before any user logs in.
During the boot process:
- The kernel loads and initializes hardware
- The init system (systemd, init, launchd) starts
- Services begin launching in dependency order
- Network interfaces come up and start accepting connections
- Scheduled tasks from previous sessions may execute
All of this happens before any human can intervene. If malicious code executes during boot, it has the opportunity to:
- Subvert services before they're monitored
- Modify logs before they're collected
- Establish network connections before firewalls are fully active
- Hide itself in the noise of normal boot activity
This is why boot integrity matters. Technologies like Secure Boot, Measured Boot, and boot attestation exist precisely because the boot sequence is a critical window where trust is established — or subverted.
Key insight: by the time you see a login prompt, hundreds of security decisions have already been made. The boot sequence is where trust begins.
Real-World Context: Service Compromise in Practice
Service compromise is not theoretical. It is a standard technique in real-world attacks:
Equifax Breach (2017): Attackers exploited a vulnerability in Apache Struts, a web application framework running as a service. The compromised service provided the initial foothold from which attackers moved laterally, eventually exfiltrating personal data on 147 million people. The service was network-facing, ran with sufficient privileges to access backend databases, and was not patched despite a known vulnerability.
Mirai Botnet (2016): Mirai targeted IoT devices by attacking their management services — specifically, devices with default credentials on Telnet and SSH services. The malware didn't exploit software vulnerabilities; it simply logged into services that were left open and poorly configured. The resulting botnet launched the largest DDoS attacks ever recorded at the time.
SolarWinds Supply Chain Attack (2020): Attackers compromised the build process for SolarWinds Orion, inserting malicious code that would run as a service on every system where Orion was installed. Because the software ran as a trusted monitoring service with elevated privileges, the backdoor had ideal conditions for persistent, stealthy access.
Common thread: in each case, attackers targeted services because services offered authority, persistence, and invisibility that user-level compromise could not provide.
Guided Lab: Observing the Always-On Layer
This lab focuses on observation, not modification. You will examine the services running on your system and reason about their security implications.