A web server process running as root is exploited through a buffer overflow. Compared to the same exploit against a restricted web server user, what additional risk does the root process create?
ANo additional risk — buffer overflows give the same access regardless of process privilege
BThe attacker gains full system control, since root has unrestricted access to all kernel resources and all user data
CThe attacker can access the web server's files but no other users' files
DA root process is harder to exploit because it has better memory protection
This illustrates the principle of least privilege. A root exploit immediately grants the attacker full system control — they can read any file, modify kernel state, install backdoors, and access all accounts. The same exploit against a restricted web server user limits the attacker to only what that user account can access (its document root, log files). Principle of least privilege is about containing the blast radius: the damage of a successful exploit is bounded by the permissions of the exploited process.
Question 2 Multiple Choice
What is the correct relationship between authentication and authorization in OS security?
AThey are synonyms — both refer to verifying that an access request is legitimate
BAuthentication determines what you are allowed to do; authorization verifies your identity
CAuthentication verifies identity ('who are you?'); authorization enforces permissions ('what can you do?')
DAuthorization happens first — you must have permission before you can authenticate
Authentication and authorization are sequential but distinct. Authentication comes first: the system verifies your identity (login password, SSH key, biometric). Once identity is established, authorization enforces what that identity is permitted to do (read this file? execute that program?). Option B reverses them — a classic confusion. A user who fails authentication is stopped before authorization even runs. A user who passes authentication might still be denied by authorization (e.g., a regular user trying to access root-owned files).
Question 3 True / False
A user-mode process cannot directly read the memory of another process — it must make a system call that the kernel validates.
TTrue
FFalse
Answer: True
This is exactly what hardware protection rings enforce. User-mode code (ring 3) has no access to arbitrary physical memory — the CPU's memory management unit separates address spaces under kernel supervision. Reading another process's memory requires a privileged system call (e.g., ptrace in Linux) that triggers a controlled transition to kernel mode (ring 0), where the kernel validates whether the request is permitted. Without this enforcement, process isolation would be impossible and any process could read any other process's data.
Question 4 True / False
OS security is primarily about encryption — a system with strong encryption is fundamentally secure.
TTrue
FFalse
Answer: False
Encryption addresses one dimension of the CIA triad (confidentiality), but OS security encompasses all three: Confidentiality, Integrity, and Availability. A perfectly encrypted system can still be compromised by privilege escalation (an unprivileged user gains root through a kernel bug), a denial-of-service attack (availability), or an integrity violation (an attacker modifies data without reading it). Authentication, authorization, auditing, protection rings, and the principle of least privilege are all non-cryptographic OS security mechanisms that are equally foundational.
Question 5 Short Answer
Explain why privilege escalation is considered the central threat in OS security, and describe one OS mechanism that makes it difficult.
Think about your answer, then reveal below.
Model answer: Privilege escalation is central because the entire OS security model depends on the kernel/user boundary. If an attacker can escalate from user mode to kernel mode (or from an unprivileged user to root), they bypass all other access controls — every other security mechanism becomes moot. One mechanism that raises the bar is the system call interface: all transitions from user mode to kernel mode go through a controlled gate that validates the request, checks permissions, and prevents user code from arbitrarily jumping into kernel execution paths.
The OS security model assumes attackers may execute malicious code at user privilege level. The real question is always: can they escalate? Privilege separation (running services as restricted users), mandatory access controls, and careful validation of system call inputs all reduce the attack surface. A single kernel bug — a failure to validate a pointer in a syscall handler — can let user code corrupt kernel memory structures and seize control, which is why every layer of the OS security model exists to make this as difficult as possible.