Lesson 12.1: Security Principles

01 Introduction

The previous units presented the operating system as a manager: it multiplexes the processor among the processes (Unit 5), it allocates and protects the memory (Units 8 and 9), it organizes the storage (Unit 10), and it drives the I/O devices (Unit 11). This unit presents the operating system in its other role: the protector. The two roles are intertwined — the memory's protection is a security mechanism, the file system's permissions are a security policy, and the isolation between the processes is a security boundary — but the security's concerns are broader than the resource management's: the security must account for the users' mistakes, the programs' bugs, and the attackers' deliberate attempts to violate the system's policies.

The operating system's security has three goals, and the goals are the CIA triad:

Confidentiality. The data is disclosed only to the authorized parties. The confidentiality's violations are the unauthorized reads: an attacker who reads a file they should not read, a program that leaks a password, a network connection that exposes the traffic to an eavesdropper.
Integrity. The data is modified only by the authorized parties, and the modifications are the intended ones. The integrity's violations are the unauthorized writes: an attacker who changes a file they should not change, a program that corrupts the data, a network connection that lets the traffic be modified in transit.
Availability. The system's resources are available to the authorized parties when they are needed. The availability's violations are the denial of service: an attacker who floods the network, a program that consumes the processor, a disk that fails.

The three goals are the security's foundation, and the security's mechanisms are the ways the goals are achieved. But the goals are not the security's whole story: a system that satisfies the three goals for the authorized parties may still be insecure, because the authorization itself may be wrong (a user may be granted access they should not have), or the authentication may be weak (an attacker may impersonate an authorized user), or the auditing may be absent (an attacker's actions may go unnoticed). The security is therefore a system property: it depends on the authentication, the authorization, the access control, the auditing, and the users' behaviour, and the weakest link determines the system's strength.

This lesson presents the security's principles. It defines the CIA triad and the other goals. It presents the threats, the vulnerabilities, and the attacks, and the threat models and the attack surfaces. It presents the distinction between the security policy (what the system should do) and the security mechanism (how the system does it), and the reference monitor that mediates the accesses. It presents the Saltzer and Schroeder principles — the classical design principles that the secure systems share — and the defence in depth that the modern systems use. It presents the trusted computing base and the AAA model (the authentication, the authorization, and the auditing) that the operating system's security implements. It closes with the operating system's role in the security and the lesson's synthesis.

Prerequisites

This lesson builds on the earlier units. The process and the thread concepts (Unit 3), the CPU scheduling and the context switch (Unit 5), the memory management and the virtual memory (Units 8 and 9), the file system and the permissions (Unit 10), and the I/O subsystem (Unit 11) are all assumed. The kernel-mode and user-mode distinction from Lesson 1.4 is the basis for the discussion of the reference monitor and the trusted computing base, and the system-call interface from the same lesson is the basis for the discussion of the mediation. No new operating-system concepts are introduced; the lesson is about the security's principles and the operating system's role in the security. Familiarity with the Linux command line from Lesson 2.2 is helpful, since the interactive activity uses standard Unix tools.

02 Learning objectives

By the end of this lesson you will be able to

Define the security's goals (the CIA triad) and explain the confidentiality, the integrity, and the availability.
Distinguish the threats, the vulnerabilities, and the attacks, and explain the threat model and the attack surface.
Distinguish the security policy from the security mechanism, and explain the reference monitor and its requirements.
Describe the Saltzer and Schroeder principles of secure design and explain each principle's role.
Explain defence in depth, the trusted computing base, and the AAA model (the authentication, the authorization, and the auditing).
Explain the operating system's role in the security, and describe the ways that the operating system enforces the security policies.

This lesson contributes to U12.1 and U12.2, and to course learning outcomes CLO1, CLO7, and CLO8.

03 Required reading

Operating System Concepts — Chapter 16, Security, Sections 16.1–16.3. The standard treatment of the security's goals, the threats, the attacks, and the design principles.
OSTEP — the Security chapters (Chapter 53, Cryptographic Primitives, and the following chapters). OSTEP's treatment of the security's foundations and its discussion of the protection's mechanisms is the clearest available account, and it is the basis for the worked example in this lesson.
Tanenbaum & Bos — Modern Operating Systems, Chapter 9, Security, Sections 9.1–9.3. A complementary treatment that develops the security's goals, the threats, and the design principles from first principles.
Saltzer, J. H., & Schroeder, M. D. — The Protection of Information in Computer Systems. Proceedings of the IEEE, 1975. The paper that introduced the design principles that the modern secure systems still follow. The paper's eight principles are the basis for this lesson's core content.
Anderson, R. — Security Engineering, 2nd ed. Wiley, 2008. The comprehensive treatment of the security's engineering, including the threats, the attacks, and the design principles.
Bishop, M. — Computer Security: Art and Science, 2nd ed. Addison-Wesley, 2019. The formal treatment of the security's models and the design principles.
NIST SP 800-160 — Systems Security Engineering. The National Institute of Standards and Technology's guide to the security's engineering, including the design principles and the threat models.
Linux man pages: man 7 capabilities, man 7 credentials, man 7 unix, man 5 passwd, man 5 shadow, man 5 sudoers, man 8 sudo, man 1 id, man 1 whoami, man 8 setcap, man 1 getcap, man 1 chmod, man 1 chown, man 8 auditctl, man 8 ausearch, man 8 aureport, man 1 last, man 1 lastlog, man 8 selinux (if available), man 8 apparmor (if available).

Reading strategy

Read the Silberschatz chapter first for the formal terminology: the security's goals, the threats, the attacks, and the design principles. Then read the Saltzer and Schroeder paper. The paper is short (about 20 pages), and it is the source of the design principles that the modern systems follow; its eight principles are the lesson's core content, and their discussion in the paper is the clearest statement of the principles' rationale. The OSTEP and the Tanenbaum chapters are the complementary views, and they are worth reading for the discussion of the protection's mechanisms and the operating system's role. Anderson's Security Engineering is the comprehensive reference, and it is worth consulting for the threats and the attacks that the modern systems face. Finally, the Linux man pages are the practical tools: id and whoami show the current user's identity, chmod and chown set the files' permissions, getcap and setcap manage the process capabilities, and ausearch and aureport examine the audit log. Pay particular attention to the distinction between the policy (what the system should allow) and the mechanism (how the system enforces the allowance). The distinction is the security's central design principle: the mechanism can be verified (the kernel's code can be audited), and the policy can be changed (the administrator's configuration), and the two are independent. A system that confuses the two — a mechanism that hard-codes the policy, or a policy that depends on the mechanism's bugs — is a system that cannot be made secure.

04 Core content

4.1 The security's goals

The security's goals are the properties that a secure system must provide. The classical formulation is the CIA triad:

Confidentiality: The data is disclosed only to the authorized parties. The confidentiality's mechanisms are the access control (the files' permissions, the processes' isolation), the encryption (the data's transformation so that only the key holders can read it), and the authentication (the parties' identity verification). The confidentiality's violations are the unauthorized reads: an attacker who reads a file they should not read, a program that leaks a password, a network connection that exposes the traffic to an eavesdropper. The confidentiality's enforcement is the most visible of the security's mechanisms, and it is the one the users think of first when they think of the security.
Integrity: The data is modified only by the authorized parties, and the modifications are the intended ones. The integrity's mechanisms are the access control (the write permissions), the checksums (the data's verification, as in Lesson 10.6), the transactions (the modifications' atomicity, as in Lesson 10.6's journaling), and the authentication (the writers' identity verification). The integrity's violations are the unauthorized writes: an attacker who changes a file they should not change, a program that corrupts the data, a network connection that lets the traffic be modified in transit. The integrity's enforcement is subtler than the confidentiality's: a corrupted file may be detected only when it is read, and the corruption's source (the disk's failure, the software's bug, or the attacker's modification) may be hard to determine. The observation is the reason the modern systems' checksums (Lessons 10.6 and 11.7) are important: they turn the silent corruption into the detected corruption.
Availability: The system's resources are available to the authorized parties when they are needed. The availability's mechanisms are the redundancy (the RAID arrays, the mirrors, the backups), the resource management (the quotas, the scheduling), and the denial-of-service defences (the rate limiting, the firewalls). The availability's violations are the denial of service: an attacker who floods the network, a program that consumes the processor, a disk that fails. The availability's enforcement is the most neglected of the three goals: the confidentiality and the integrity get the most attention, and the availability is the one that the users notice first when it is violated. The observation is the reason the modern systems' designs (the RAID, the load balancing, the rate limiting) treat the availability as a first-class requirement.

The CIA triad is the security's classical formulation, but it is not the whole story. The modern security's goals also include:

Authenticity. The data's and the parties' origin is genuine: the sender is who they claim to be, and the data was created by them. The authenticity's mechanisms are the digital signatures, the message authentication codes (the MACs), and the authentication protocols.
Accountability. The parties' actions can be traced to them: the system records who did what, and the records can be verified. The accountability's mechanisms are the auditing (the logs), the non-repudiation (the digital signatures), and the accounting.
Non-repudiation. The parties cannot deny their actions: the evidence is strong enough that a party cannot credibly deny having performed an action. The non-repudiation's mechanisms are the digital signatures and the trusted timestamps.
Privacy. The personal data is collected, stored, and used in accordance with the parties' expectations and the law. The privacy's mechanisms are the access control, the anonymization, and the data's minimization.

The goals are the security's what: what the system should provide. The security's how — the mechanisms, the policies, and the designs — is the subject of the rest of the unit.

4.2 Threats, vulnerabilities, and attacks

The security's discussion requires the precise distinction of three concepts:

Threat: A potential cause of an unwanted incident: the circumstances and the actors that could violate the security's goals. The threats can be natural (the fires, the floods, the power failures), accidental (the users' mistakes, the operators' errors), or deliberate (the attackers' actions). The deliberate threats are the ones the security usually focuses on, and they are the ones the lesson's discussion assumes. The threat's actors are the adversaries or the attackers, and their capabilities, resources, and motivations are the security's design's inputs.
Vulnerability: A weakness in the system that a threat could exploit. The vulnerabilities can be the design's flaws (the protocol's logic, the access control's model), the implementation's bugs (the buffer overflows, the integer overflows, the race conditions), the configuration's errors (the default passwords, the open ports, the unnecessary services), or the users' behaviour (the weak passwords, the phishing's clicks). The vulnerabilities are the security's weak links, and the attacker needs only one to compromise the system.
Attack: The exploitation of a vulnerability: the adversary's deliberate attempt to violate the security's goals. The attacks can be passive (the eavesdropping, the traffic analysis) or active (the modification, the injection, the replay, the denial of service); they can be local (the attacker has an account on the system) or remote (the attacker reaches the system through the network); and they can be targeted (the specific victim) or indiscriminate (the mass scanning and the automated exploitation).

The three concepts form the security's chain: a threat exploits a vulnerability to carry out an attack, and the attack violates a security goal. The chain's defence can be at any link: the threat can be deterred (the attacker's cost raised), the vulnerability can be removed (the flaw fixed), and the attack's effect can be mitigated (the damage's limitation). The modern security's practice is the defence in depth (section 4.6): the defences at the multiple links, so that the failure of one defence does not compromise the system.

4.3 The threat model and the attack surface

The threat model is the specification of the threats that a system's security is designed to address. It defines:

The adversaries' capabilities. What can the attacker do? The capabilities can range from the network-level (the attacker can send and receive the packets) to the local (the attacker has an account on the system) to the physical (the attacker has access to the hardware) to the supply-chain (the attacker has modified the hardware or the software before the delivery).
The adversaries' resources. How much can the attacker spend? The resources include the computation, the storage, the network's bandwidth, and the budget. The script kiddie (the low-resource attacker), the organized crime (the medium-resource attacker), and the nation-state (the high-resource attacker) have different capabilities, and the system's defence must match the threat's level.
The adversaries' goals. What does the attacker want? The goals can be the data theft (the confidentiality's violation), the data modification (the integrity's violation), the service disruption (the availability's violation), the financial gain (the ransomware, the fraud), or the reputation's damage (the defacement, the doxing).
The system's assets. What is worth protecting? The assets include the data (the users' files, the credentials, the keys), the services (the network, the storage), and the reputation (the trust, the brand).

The threat model's specification is the security's first design step, and its neglect is the security's most common mistake. A system that does not specify its threat model cannot evaluate its defences: the defences may be too strong (the cost's waste) or too weak (the threat's exposure), and the evaluation cannot distinguish the two. The observation is the reason the modern security's practice (the NIST's frameworks, the threat modelling's methodologies) begins with the threat model's specification.

The attack surface is the set of the system's components that an attacker can interact with: the network's services (the ports, the protocols), the local's interfaces (the system calls, the device files, the setuid programs), the users' interactions (the emails, the websites, the USB drives), and the supply chain (the software's dependencies, the hardware's sources). The attack surface's reduction is a security principle: the fewer the components the attacker can reach, the fewer the vulnerabilities the attacker can exploit. The principle's practical applications are the unnecessary services' removal (a server that does not need the web server should not run it), the ports' closing (the firewall's rules), and the interfaces' minimization (the system calls' restriction, the sandboxing).

4.4 The security policy and the mechanism

The security's design distinguishes two concepts:

Security policy: The specification of what the system should allow: the subjects (the users, the processes), the objects (the files, the devices, the network's connections), and the operations (the reads, the writes, the executions) that are permitted. The policy is the system's requirements: it is determined by the stakeholders' needs, the law, and the organization's rules, and it can be expressed formally (the access control matrices, the Bell-LaPadula model, the Biba model; Lesson 12.4) or informally (the administrators' guidelines).
Security mechanism: The specification of how the system enforces the policy: the access control's implementation (the permissions' checking, the capabilities, the mandatory access control), the authentication's protocols (the passwords, the keys, the biometrics), and the auditing's machinery. The mechanism is the system's implementation: it is determined by the engineers' choices, and its correctness is verified by the code's audit and the testing.

The policy and the mechanism's distinction is the security's central design principle: the two are independent, and the mechanism should enforce the policy without hard-coding it. The independence's rationale is the security's evolution: the policy changes (the organization's rules, the law, the users' needs) more often than the mechanism does, and a system whose mechanism hard-codes its policy must be rebuilt when the policy changes. The classical example is the access control's design: a system whose kernel hard-codes the "the owner can read, the others cannot" rule must be rebuilt when the organization adopts a different rule, while a system whose kernel enforces the policy's specification (the files' permission bits, the access control lists, the capabilities) can accommodate the change by the policy's reconfiguration.

The mechanism's design has one central requirement: the reference monitor. The reference monitor is the mechanism's abstract model, and it must satisfy three properties:

It must be tamper-proof. The attacker cannot modify or bypass the reference monitor: it runs in the kernel's mode, and the user-mode programs cannot modify its code or its data.
It must be always invoked. Every access to every object must be mediated by the reference monitor: the mechanism cannot be bypassed by an alternate path (a direct hardware access, an unprotected cache, a side channel).
It must be small enough to be verified. The reference monitor's code and its data structures must be small enough that their correctness can be verified (the formal proof, the code's audit, the exhaustive testing). The requirement is the security's most demanding: a large reference monitor cannot be verified, and an unverified reference monitor cannot be trusted.

The reference monitor's three properties are the security's classical design's core. The modern operating systems' designs (the Linux kernel's security modules, the microkernels' servers, the hypervisors) are the different balances among the three: a larger reference monitor (the monolithic kernel) is more capable but harder to verify, and a smaller one (a microkernel's security server) is easier to verify but more limited in its capabilities.

4.5 The Saltzer and Schroeder principles

The Saltzer and Schroeder principles are the eight design principles that the paper The Protection of Information in Computer Systems (1975) introduced. The principles have been the secure systems' foundation for nearly five decades, and they are still the standard against which the modern systems' designs are evaluated:

1. Economy of mechanism: The security's mechanism should be as simple and as small as possible. The principle's rationale is the design's and the implementation's verifiability: a simple mechanism is easier to understand, to test, and to verify, and it has fewer bugs. The principle's applications are the small reference monitor, the simple access control's model, and the minimal interfaces.
2. Fail-safe defaults: The access's decisions should be based on the permission's grant rather than the permission's denial: the default should be the denial, and the access should be granted only when the policy explicitly allows it. The principle's rationale is the errors' direction: a system that fails open (the default is the permission) grants the access when its policy is wrong or missing, while a system that fails closed (the default is the denial) denies the access when its policy is wrong or missing. The principle's applications are the file systems' default permissions (the newly created files are readable only by the owner), the firewalls' default policies (the deny-all's rule), and the authentication's defaults (the access is denied until the authentication's success).
3. Complete mediation: Every access to every object should be checked against the policy. The principle's rationale is the access's uniformity: a system that checks the access at the open time only (and not at the read time) can be bypassed by the file's replacement (the time-of-check to time-of-use or the TOCTOU's race), and a system that checks the access for the file's reads but not its memory maps can be bypassed by the mmap's use. The principle's applications are the reference monitor's always-invoked's property, the system calls' uniform mediation, and the modern systems' file's handles (the descriptor's binding to the object rather than the name).
4. Open design: The security should not depend on the design's secrecy: the mechanism should be public, and its security should depend on the keys (or the credentials) rather than the design's obscurity. The principle's rationale is the secrecy's fragility: a secret design leaks (the reverse-engineering, the insider, the documentation's loss), and a system whose security depends on the secret's preservation collapses when the secret is revealed. The principle's applications are the cryptographic algorithms' public scrutiny (the AES, the RSA), the security protocols' open specifications (the TLS, the SSH), and the open-source's security (the Linux kernel's auditability). The principle is often summarized as the Kerckhoffs's principle, and it is the reason the modern cryptographic algorithms are published and analyzed by the community.
5. Separation of privilege: The access should require more than one condition to be satisfied: the privilege should be separated, so that a single compromise does not grant the access. The principle's rationale is the single-point's failure: a system whose access requires the password only can be compromised by the password's theft, while a system that requires the password and the hardware token can resist the password's theft alone. The principle's applications are the multi-factor authentication (the password and the token), the two-person's rule (the dual controls), and the privilege's separation in the kernel (the capabilities' splitting).
6. Least privilege: Every program and every user should operate with the minimum privileges necessary to complete the task. The principle's rationale is the damage's limitation: a program that runs with the administrator's privileges can damage the whole system when it is compromised, while a program that runs with the minimum privileges can damage only its own resources. The principle's applications are the users' accounts (the ordinary users do not run as the root), the services' accounts (the web server runs as the www-data user, not the root), the programs' capabilities (the fine-grained privileges instead of the root's all-or-nothing), and the sandboxing (the programs' confinement to the minimum resources). The principle is the security's most cited and the most violated: the users' convenience (the running as the administrator) conflicts with the principle, and the conflict's resolution requires the design's discipline.
7. Least common mechanism: The mechanism's sharing between the users should be minimized: the shared resources are the potential channels for the information's leakage and the interference. The principle's rationale is the sharing's risks: the shared files, the shared memory, the shared caches, and the shared devices can leak the information (the side channels) and can be the denial of service's vectors. The principle's applications are the per-process's address spaces (the virtual memory's isolation), the per-user's temporary directories (the /tmp's sticky bit), and the resources' partitioning (the cgroups, the namespaces).
8. Psychological acceptability: The security's mechanism should be easy to use, and its interface should be intuitive: the users should not be forced to make the security's decisions that they cannot understand, and the mechanism should not impose the burdens that the users will circumvent. The principle's rationale is the users' behaviour: the security's mechanisms that the users find inconvenient (the complex passwords, the frequent authentications, the slow's verifications) are the mechanisms the users bypass (the passwords' reuse, the credentials' sharing, the security's disabling), and the bypass's prevalence makes the mechanism ineffective. The principle's applications are the single sign-on's designs, the biometrics' convenience, the password managers' use, and the security's defaults (the secure configuration's out-of-the-box).

The eight principles are the secure design's classical foundation, and the modern practice has extended them. The extensions include:

The work factor (the attacker's cost's principle): the mechanism should make the attack's cost exceed the asset's value. The principle's application is the key's length's choice (a 128-bit key's brute force's cost is infeasible) and the rate limiting (the brute force's attempts' slowing).
The compromise recording (the logging's principle): the mechanism should record the compromises' evidence, so that the attacks can be detected and analyzed. The principle's application is the auditing (the system's logs, the application's logs, the network's logs).
The least astonishment (the predictability's principle): the mechanism's behaviour should be predictable, and its violations should be announced. The principle's application is the error messages' clarity and the security's notifications.

Figure 12.1 — The security's goals, the reference monitor, and the design principles. The top diagram shows the CIA triad: the confidentiality, the integrity, and the availability, with their mechanisms and their violations. The middle diagram shows the reference monitor: the subject's access's request is mediated by the reference monitor, which enforces the policy and grants or denies the access to the object; the monitor must be tamper-proof, always invoked, and small enough to verify. The bottom diagram lists the eight Saltzer and Schroeder principles and the defence in depth's layers: the physical, the network, the host, the application, the data, and the people.

4.6 Defence in depth

The defence in depth is the security's design strategy of the multiple, independent defences, so that the failure of one defence does not compromise the system. The strategy's rationale is the defences' fallibility: no single defence is perfect (the firewalls have the bypasses, the antivirus has the misses, the access controls have the flaws), and a system that relies on a single defence is a system that fails when the defence fails. The strategy's application is the layered design: the physical's security (the locks, the guards), the network's security (the firewalls, the intrusion detection), the host's security (the operating system's hardening, the patches), the application's security (the input's validation, the authentication), the data's security (the encryption, the backups), and the people's security (the training, the policies). Each layer is a defence, and the layers' combination is the system's security.

The defence in depth's design has a subtlety: the layers must be independent, and their failures must be uncorrelated. A system whose layers all depend on the same component (the same password, the same certificate, the same network's path) has a single point of failure, and the layers' apparent redundancy is an illusion. The independence's design is the challenge: the layers must be the different mechanisms (the password and the hardware token, the firewall and the host's hardening), and their failures must be the different causes (the password's theft and the token's loss, the firewall's misconfiguration and the host's vulnerability).

4.7 The trusted computing base

The trusted computing base (TCB) is the set of the system's components that must be trusted for the security's policy to be enforced. The TCB includes the hardware (the processor's protection's mechanisms, the memory's management's unit), the kernel (the reference monitor, the system calls, the device drivers), and the privileged programs (the init, the login, the sudo). The TCB's size is the security's central concern: the larger the TCB, the more the code must be verified, and the more the opportunities for the bugs and the flaws. The principle is the TCB's minimization: the security's design should keep the TCB as small as possible, so that its correctness can be established.

The TCB's minimization is the motivation for the microkernels and the hypervisors. A monolithic kernel's TCB includes the file systems, the network stacks, the device drivers, and the security's modules — millions of the lines of the code, and thousands of the bugs. A microkernel's TCB includes only the kernel's core — the address spaces, the threads, the inter-process communication — and the file systems, the network stacks, and the drivers run as the user-mode's servers, outside the TCB. The microkernel's TCB is smaller by orders of the magnitude, and its correctness is more tractable. The trade-off is the performance (the user-mode's servers' context switches, the IPC's overhead) and the complexity (the system's decomposition into the servers), and the modern systems' designs (the Linux kernel's modules, the QNX's microkernel, the seL4's formally verified microkernel) are the different balances.

4.8 The AAA model

The AAA model is the security's operational framework: the authentication, the authorization, and the accounting (or the auditing). The three are the security's operational pillars, and they are the subject of the rest of the unit:

Authentication: The verification of a subject's identity: the subject claims to be a particular user (or a process, or a device), and the system verifies the claim. The authentication's factors are the knowledge (something the subject knows: the password, the PIN, the answer to a question), the possession (something the subject has: the hardware token, the smart card, the phone), and the inherence (something the subject is: the fingerprint, the retina, the voice). The multi-factor authentication combines the factors from the different categories, and it is the separation of privilege's application (the principle 5). Lesson 12.2 presents the authentication.
Authorization: The determination of what an authenticated subject is allowed to do: the subject's identity is known, and the system determines the resources the subject can access and the operations the subject can perform. The authorization's models are the discretionary access control (the DAC, the owner's discretion), the mandatory access control (the MAC, the system's policy), and the role-based access control (the RBAC, the roles' assignment). The authorization's mechanisms are the access control lists (the ACLs), the capabilities, the permissions' bits, and the security labels. Lessons 12.3 and 12.4 present the authorization and the access control models.
Accounting (auditing): The recording of the subjects' actions, so that the security's violations can be detected and analyzed. The accounting's records are the audit logs: the logins, the accesses, the modifications, the failures. The accounting's purposes are the detection (the violations' discovery), the analysis (the incidents' investigation), the deterrence (the attackers' discouragement, through the accountability), and the compliance (the regulations' evidence). The accounting's design has the trade-offs: the logging's overhead (the performance's cost), the storage's cost (the logs' volume), and the privacy's concerns (the logs' personal data). Lesson 12.5 presents the Linux security's auditing.

The AAA model's three pillars are the security's operational sequence: the subject is authenticated (who are you?), the subject is authorized (what can you do?), and the subject's actions are accounted (what did you do?). The three are the security's operational foundations, and their implementation is the operating system's security's core.

4.9 The operating system's role in the security

The operating system's security role is the mediation of the resources' accesses: the operating system's kernel is the reference monitor that mediates every access to every resource, and its mechanisms are the enforcement of the security's policies. The operating system's security roles are:

The processes' isolation. The operating system's kernel gives each process its own address space, so the processes cannot read or write each other's memory. The isolation is the memory management's security's role (Lesson 9.3's page tables, Lesson 9.5's protection's bits), and it is the foundation of the multi-user systems' security.
The files' protection. The operating system's file system gives each file its permissions (the owner, the group, the others' bits; Lesson 10.2's metadata), and the kernel checks the permissions on every access. The protection is the file system's security's role, and it is the users' most visible interaction with the security.
The authentication's enforcement. The operating system's login's machinery (the PAM's stack, the password's files, the credentials' management) verifies the users' identities, and the kernel's credentials structure records the identities for the subsequent accesses.
The privileged operations' control. The operating system's kernel restricts the privileged operations (the hardware's access, the devices' configuration, the kernel's modules' loading) to the privileged processes. The control is the privilege's security's role, and its mechanisms are the capabilities (the Linux's capabilities, Lesson 12.5) and the access control's policies.
The auditing. The operating system's kernel records the security-relevant events (the logins, the accesses, the modifications, the failures) in the audit logs, so that the violations can be detected and analyzed.
The security's boundaries. The operating system's kernel enforces the security's boundaries between the users, between the processes, and between the kernel and the user space. The boundaries are the security's foundation: the applications' security builds on the kernel's boundaries, and the kernel's boundaries' failure compromises the applications.

The operating system's security role's scope is the system's local resources: the processor, the memory, the storage, and the devices. The network's security (the firewalls, the TLS, the VPNs) and the application's security (the input's validation, the sessions' management, the web's security) are the other layers' roles, and the operating system's security is the foundation on which the other layers build. The observation is the reason the operating system's security is the necessary condition for the system's security: an application cannot be secure on an insecure operating system, and the operating system's security's failure compromises every application that runs on it.

4.10 Common misconceptions

"The security is a product."

The security is not a product that can be bought and installed; it is a process that must be designed, implemented, maintained, and monitored. The security's products (the firewalls, the antivirus, the intrusion detection's systems) are the tools that support the process, and their effectiveness depends on the process's quality. The security's process includes the threat model's specification, the design's principles, the implementation's testing, the deployment's configuration, the monitoring's detection, and the incidents' response.

"The security depends on the secrecy of the design."

The security should not depend on the design's secrecy (the principle 4, the open design). A secret design leaks (the reverse-engineering, the insider, the documentation's loss), and a system whose security depends on the secret's preservation collapses when the secret is revealed. The security should depend on the keys (or the credentials), which can be changed and protected, not on the design's obscurity. The observation is the reason the modern cryptographic algorithms are published and analyzed by the community.

"The security is the administrator's responsibility."

The security is everyone's responsibility: the designers, the developers, the administrators, and the users. The designers specify the threat model and the security's requirements; the developers implement the secure code; the administrators configure the systems and monitor the logs; the users choose the strong passwords and recognize the phishing. The security's weakest link determines the system's strength, and the weakest link is often the users' behaviour. The observation is the reason the security's training and the awareness's programs are the security's essential components.

"The security can be perfect."

The security cannot be perfect: the systems have the bugs, the attackers have the resources, and the environments change. The security's goal is the risk's management: to reduce the risk to an acceptable level, given the assets' value, the threats' capabilities, and the defences' cost. The observation is the reason the security's practice is the risk's assessment (the threats' identification, the vulnerabilities' evaluation, the impacts' estimation) and the defence in depth (the multiple defences, so that the single defence's failure is not the system's compromise).

"The encryption solves the security."

The encryption is a tool, not a solution: it protects the confidentiality (and, with the signatures, the integrity and the authenticity), but it does not protect against the other threats (the malware, the phishing, the misconfiguration, the insider). The encryption's effectiveness depends on the keys' management (the keys' generation, distribution, storage, rotation, and destruction), and the keys' compromise compromises the encryption. The encryption is one of the security's layers, not the security's whole.

"The default configuration is secure."

The default configuration is often insecure: the vendors' defaults favour the convenience and the compatibility over the security, and the default passwords, the open ports, and the unnecessary services are the common vulnerabilities. The observation is the reason the security's practice includes the hardening: the default configuration's review, the unnecessary services' removal, the passwords' change, and the policies' application. Lesson 12.7 presents the operating system's hardening.

"The antivirus is enough."

The antivirus is a detection tool, not a prevention's guarantee: it detects the known malware (the signatures) and the suspicious behaviour (the heuristics), but it misses the new malware (the zero-days), the targeted attacks (the advanced persistent threats), and the non-malware's attacks (the phishing, the social engineering). The antivirus is one of the defence in depth's layers, and its effectiveness depends on the other layers' strength.

"The security is the same as the privacy."

The security and the privacy are related but distinct: the security protects the data from the unauthorized access, and the privacy protects the individuals' control over their personal data. A system can be secure (the data is protected from the outsiders) but not private (the system's operator can access the data), and a system can be private (the data is not collected) but not secure (the data is not protected). The two are the different requirements, and the systems' designs must account for both.

05 Worked example

The following example analyzes a concrete security scenario through the lesson's principles: a web server's compromise, its causes, and the defences that the principles would have provided.

Analyzing a web server's compromise

Consider a small organization's web server. The server runs the Linux operating system, the Apache web server, and a custom application written in PHP. The server holds the organization's website and a database with the customers' information. The server's administrator has configured it with the distribution's defaults, and the server runs the web server as the root user (because the configuration's documentation suggested it for the simplicity).

An attacker discovers the server through the internet's scanning, and the attack proceeds in four stages:

The reconnaissance. The attacker scans the server's ports and identifies the open services: the SSH (the port 22), the HTTP (the port 80), and the MySQL (the port 3306, the database's port, which is exposed to the internet).
The initial access. The attacker exploits a vulnerability in the custom PHP application (an SQL injection in the login's form), and obtains the application's database's credentials. The credentials give the attacker the read and the write access to the database, and the attacker extracts the customers' information.
The privilege's escalation. The attacker uses the application's vulnerability (a file upload's feature that does not validate the uploaded files' types) to upload a web shell (a PHP script that executes the arbitrary commands). Because the web server runs as the root user, the web shell's commands run with the root privileges, and the attacker has the server's full control.
The persistence and the exfiltration. The attacker installs a backdoor (a reverse shell that connects to the attacker's server), and exfiltrates the organization's data and its private keys.

The attack's analysis through the lesson's principles reveals the design's failures:

The least privilege's violation. The web server runs as the root user, so the application's compromise gives the attacker the whole system's control. If the web server ran as a dedicated www-data user (the principle 6), the attacker's web shell would run with the www-data's privileges, and the escalation would require a second vulnerability (the local privilege's escalation).
The attack surface's reduction's failure. The MySQL's port is exposed to the internet (the principle's application), so the attacker can reach the database directly. If the database were bound to the localhost's interface (the 127.0.0.1) and the firewall blocked the port 3306 (the principle 1, the economy of mechanism), the attacker could not reach the database except through the application.
The complete mediation's failure. The application's file upload's feature does not validate the uploaded files' types (the principle 3, the complete mediation), so the attacker can upload a PHP script and execute it. If the upload's feature validated the files' types and stored them outside the web's root (the defence in depth's layers), the web shell could not be executed.
The fail-safe defaults' violation. The distribution's defaults (the principle 2) leave the unnecessary services (the MySQL's port, the SSH's password authentication) and the permissive configurations. If the defaults were the secure ones (the services' minimization, the key-based SSH, the database's local binding), the attack's surface would be smaller.
The defence in depth's absence. The organization relied on a single defence (the application's security), and the application's vulnerability was the system's compromise. If the design had the multiple layers (the network's firewall, the host's hardening, the application's validation, the database's encryption, the auditing's monitoring), the single vulnerability would not have compromised the whole system.
The open design's absence in the application. The custom PHP application's code was not reviewed (the principle 4's spirit, the open design's scrutiny), so the SQL injection and the file upload's flaws went unnoticed. If the application's code had been the subject of a security review (the static analysis, the penetration's testing), the flaws would have been detected before the deployment.

The defences that the principles would have provided

The lesson's principles suggest the defences that the organization should have implemented:

Principle	Defence	Effect on the attack
Least privilege	The web server runs as `www-data`; the database runs as `mysql`; the application's account has only the database's required privileges	The privilege's escalation requires a second vulnerability; the database's compromise's impact is limited
The attack surface's reduction	The firewall blocks the ports 22 and 3306 (except from the management's network); the database is bound to the localhost	The attacker cannot reach the database directly; the SSH's brute force is limited
Complete mediation	The application validates the inputs (the SQL's parameters, the file uploads' types); the web server restricts the executable files' locations	The SQL injection and the file upload's attack fail
Fail-safe defaults	The services' minimization; the key-based SSH; the database's least privilege; the web server's secure configuration	The attack's surface is smaller; the initial access is harder
Defence in depth	The network's firewall; the host's hardening; the application's validation; the database's encryption; the auditing's monitoring	The single defence's failure is not the system's compromise; the attack's stages are detected
Open design	The application's code's review; the static analysis; the penetration's testing; the dependencies' updates	The SQL injection and the file upload's flaws are detected before the deployment
Separation of privilege	The multi-factor authentication for the administrators; the two-person's rule for the sensitive operations	The administrator's credentials' theft is not sufficient for the access
Auditing	The application's log; the web server's log; the database's audit; the operating system's audit; the log's monitoring	The attack's stages are recorded; the incident's response is faster

The attack's cost-benefit's analysis

The security's design is the risk's management, and the risk's analysis is the cost-benefit's comparison. The attack's cost for the attacker and the defence's cost for the organization are the two sides of the analysis:

Stage	Attacker's cost (without the defences)	Attacker's cost (with the defences)
The reconnaissance	Low (the automated scanning)	Low (the scanning still works, but the services are fewer)
The initial access	Low (the known vulnerability in the custom application)	Higher (the inputs' validation blocks the SQL injection; the review catches the flaw)
The privilege's escalation	None (the application runs as root)	High (a local privilege's escalation is required, and the known vulnerabilities are patched)
The persistence	Low (the root's access)	High (the web shell runs as the unprivileged user; the audit detects the anomalous commands)

The table shows the defences' effect: the least privilege raises the escalation's cost from zero to high, the complete mediation raises the initial access's cost, and the auditing raises the persistence's cost. The attacker's total cost's increase is the defences' measure, and it is the reason the principles' application is the security's foundation: the principles raise the attack's cost relative to the asset's value, and the attacker's rational choice is to move to an easier target.

Observing the security's state on a live system

The Linux tools let an administrator inspect the system's security's state: the identity, the permissions, the capabilities, the services, and the audit's logs.

# Show the current user's identity
id
whoami
groups

# Show the recent logins
last | head -10
lastlog | head -10

# Show the files' permissions
ls -la /etc/passwd /etc/shadow
ls -la /var/www/ 2>/dev/null

# Show the running services and their listening ports
ss -tlnp
systemctl list-units --type=service --state=running 2>/dev/null | head -20

# Show the processes' capabilities (the fine-grained privileges)
getcap -r / 2>/dev/null | head -10

# Show the setuid and setgid programs (the privilege's escalation's vectors)
find / -perm -4000 -type f 2>/dev/null | head -20

# Show the kernel's security modules
ls /sys/kernel/security/ 2>/dev/null
cat /sys/kernel/security/lsm 2>/dev/null

# Show the audit's status and its recent events
sudo auditctl -s 2>/dev/null
sudo ausearch -ts recent 2>/dev/null | head -20

The commands' outputs show the security's state: the current user's identity and the groups, the recent logins, the files' permissions (the /etc/shadow's restrictive permissions), the running services and their listening ports, the processes' capabilities, the setuid programs, the kernel's security modules, and the audit's events. The inspection is the administrator's first step in the security's assessment, and it is the basis for the hardening's decisions.

06 Interactive activity

Activity · explore the security principles on a live system

The goal of this activity is to use the Linux command line to inspect the system's security's state, to identify the principles' violations, and to apply the principles' defences. Work through the steps in your course VM.

Inventory the identities and the permissions. Use id, ls, and the files' permissions to examine the system's identity and permission's model.
```
# Show the current user's identity
id
whoami
groups

# Show the system's users
cat /etc/passwd | head -20
sudo cat /etc/shadow 2>/dev/null | head -5

# Show the files' permissions
ls -la /etc/passwd /etc/shadow
ls -la /home/
ls -la /tmp/
```
What is the current user's identity and the groups? What are the /etc/shadow's permissions? Why are they restrictive? What are the /tmp's permissions, and what does the sticky bit do? Write down what you find.
Inventory the running services and the listening ports. Use ss and systemctl to identify the system's attack surface.
```
# Show the listening ports
ss -tlnp
sudo ss -tlnup

# Show the running services
systemctl list-units --type=service --state=running 2>/dev/null

# Show the enabled services
systemctl list-unit-files --state=enabled 2>/dev/null | head -20
```
Which ports are listening? Which services are running? Which of them are necessary for the system's function? Which could be removed (the attack surface's reduction)? Write down your analysis.
Inventory the privilege's escalation's vectors. Use find and getcap to identify the setuid programs and the capabilities.
```
# Show the setuid and setgid programs
find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null | head -20

# Show the processes' capabilities
getcap -r / 2>/dev/null

# Show the capabilities' definitions
man 7 capabilities | head -40
```
How many setuid programs are there? Are they all necessary? Are there any capabilities that surprise you? Why are the setuid programs a security's concern (the least privilege's violation)?
Examine the security's logging. Use last, lastlog, and the system's logs to examine the security's events.
```
# Show the recent logins
last | head -10
lastlog | head -10

# Show the failed logins
sudo lastb 2>/dev/null | head -10

# Show the authentication's log
sudo grep -iE 'authentication|session|failed' /var/log/auth.log 2>/dev/null | tail -20
sudo journalctl -u ssh 2>/dev/null | tail -20

# Show the audit's status
sudo auditctl -s 2>/dev/null
sudo ausearch -ts today 2>/dev/null | head -20
```
How many successful and failed logins are there? What do the authentication's logs show? Is the audit's subsystem enabled? What does the auditing tell you about the system's security's state?

Examine the kernel's security's modules. Use the sysfs interfaces to identify the kernel's security's modules.

# Show the kernel's security's modules
cat /sys/kernel/security/lsm 2>/dev/null
ls /sys/kernel/security/ 2>/dev/null

# Show the SELinux's or AppArmor's status
getenforce 2>/dev/null
sudo aa-status 2>/dev/null | head -20
sestatus 2>/dev/null | head -10

# Show the kernel's security's parameters
sysctl -a 2>/dev/null | grep -iE 'kernel.randomize|kernel.dmesg|net.ipv4.conf.all.rp_filter|net.ipv4.tcp_syncookies' | head -10

Which security's modules are enabled (the SELinux, the AppArmor)? What is their status (the enforcing, the permissive)? What are the kernel's security's parameters? What do they protect against?

Apply the least privilege's principle. Create a test service that runs with the least privilege, and observe the difference.

# Create a test script that writes to a directory
sudo mkdir -p /tmp/test-service
echo '#!/bin/sh
echo "Running as: $(id)" > /tmp/test-service/output.txt
' | sudo tee /tmp/test-service/test.sh
sudo chmod 755 /tmp/test-service/test.sh

# Run it as the root (the violation of the least privilege)
sudo /tmp/test-service/test.sh
cat /tmp/test-service/output.txt

# Create a dedicated user and run it as that user
sudo useradd -r -s /usr/sbin/nologin testuser 2>/dev/null
sudo chown testuser /tmp/test-service
sudo -u testuser /tmp/test-service/test.sh
cat /tmp/test-service/output.txt

# Clean up
sudo userdel testuser 2>/dev/null
sudo rm -rf /tmp/test-service

What is the difference between the two runs? What are the privileges of the dedicated user compared to the root's? What could the test script do in the root's case that it cannot do in the dedicated user's case?

Examine the fail-safe defaults. Use umask and the file's creation to observe the fail-safe defaults' principle.
```
# Show the current umask
umask

# Create a file and observe its permissions
touch /tmp/test-umask.txt
ls -la /tmp/test-umask.txt

# Change the umask and create another file
umask 077
touch /tmp/test-umask-2.txt
ls -la /tmp/test-umask-2.txt

# Restore the umask
umask 022

# Clean up
rm /tmp/test-umask.txt /tmp/test-umask-2.txt
```
What was the first file's permissions? What was the second's? What does the difference tell you about the fail-safe defaults' principle? Which umask is the fail-safe default (the more restrictive or the more permissive)?
Read the man pages. Read the man pages that document the security's interfaces.
```
man 7 capabilities
man 7 credentials
man 5 passwd
man 5 shadow
man 5 sudoers
man 8 sudo
man 1 id
man 8 setcap
man 1 getcap
man 8 auditctl
man 8 ausearch
man 1 last
man 1 lastlog
```
For each, write a sentence describing its main contribution to your understanding of the security's principles. The man 7 capabilities page documents the fine-grained privileges; the man 5 passwd and man 5 shadow pages document the authentication's files; the man 8 auditctl page documents the auditing's configuration.

Reflect: the security's principles are the accumulation of nearly five decades of the security's experience, and they are the standard against which the modern systems' designs are evaluated. The principles are abstract, but their application is concrete: the web server that runs as the root violates the least privilege, the open database's port violates the attack surface's reduction, the unvalidated input violates the complete mediation, and the single defence violates the defence in depth. Which of the principles from this lesson is the most violated in the systems you have seen? Which is the most important for the systems you care about? How would you explain the least privilege's principle to a developer who runs everything as the administrator? What is the right balance between the security's discipline and the users' convenience (the psychological acceptability's principle)?

07 Knowledge check

Check your understanding

Question 1

Define the CIA triad and explain each goal's meaning, its mechanisms, and its violations. Why are the three goals the security's foundation?

Show answer

The CIA triad is the security's classical formulation of its three goals. Confidentiality means that the data is disclosed only to the authorized parties. Its mechanisms are the access control (the files' permissions, the processes' isolation), the encryption (the data's transformation so that only the key holders can read it), and the authentication (the parties' identity verification). Its violations are the unauthorized reads: an attacker who reads a file they should not read, a program that leaks a password, a network connection that exposes the traffic to an eavesdropper. Integrity means that the data is modified only by the authorized parties, and the modifications are the intended ones. Its mechanisms are the access control (the write permissions), the checksums (the data's verification), the transactions (the modifications' atomicity), and the authentication (the writers' identity verification). Its violations are the unauthorized writes: an attacker who changes a file they should not change, a program that corrupts the data, a network connection that lets the traffic be modified in transit. Availability means that the system's resources are available to the authorized parties when they are needed. Its mechanisms are the redundancy (the RAID arrays, the mirrors, the backups), the resource management (the quotas, the scheduling), and the denial-of-service defences (the rate limiting, the firewalls). Its violations are the denial of service: an attacker who floods the network, a program that consumes the processor, a disk that fails. The three goals are the security's foundation because they define what the security must provide. The security's mechanisms — the authentication, the authorization, the access control, the auditing — are the ways the goals are achieved, and their effectiveness is measured by the goals' satisfaction. The triad is the security's vocabulary: the threats are the potential violations of the goals, the vulnerabilities are the weaknesses that permit the violations, and the attacks are the deliberate attempts to carry them out. The goals' formulation is the security's first step: a system that does not know what it must protect cannot protect it.

Question 2

Distinguish the threats, the vulnerabilities, and the attacks. What is a threat model, what is an attack surface, and why are they the security's first design steps?

Show answer

The three concepts form the security's chain. A threat is a potential cause of an unwanted incident: the circumstances and the actors that could violate the security's goals. The threats can be the natural (the fires, the floods), the accidental (the users' mistakes), or the deliberate (the attackers' actions). A vulnerability is a weakness in the system that a threat could exploit. The vulnerabilities can be the design's flaws, the implementation's bugs, the configuration's errors, or the users' behaviour. An attack is the exploitation of a vulnerability: the adversary's deliberate attempt to violate the security's goals. The attacks can be the passive or the active, the local or the remote, the targeted or the indiscriminate. The three form the chain: a threat exploits a vulnerability to carry out an attack, and the attack violates a security goal. The threat model is the specification of the threats that a system's security is designed to address. It defines the adversaries' capabilities (the network-level, the local, the physical, the supply-chain), the adversaries' resources (the script kiddie, the organized crime, the nation-state), the adversaries' goals (the data theft, the data modification, the service disruption), and the system's assets (the data, the services, the reputation). The attack surface is the set of the system's components that an attacker can interact with: the network's services, the local's interfaces, the users' interactions, and the supply chain. The threat model and the attack surface are the security's first design steps because they define the design's scope and its boundaries. A system that does not specify its threat model cannot evaluate its defences: the defences may be too strong (the cost's waste) or too weak (the threat's exposure), and the evaluation cannot distinguish the two. A system that does not analyse its attack surface cannot reduce it: the unnecessary services, the open ports, and the unnecessary interfaces are the vulnerabilities that the attacker can exploit, and their identification is the attack surface's reduction's first step. The observation is the reason the modern security's practice (the NIST's frameworks, the threat modelling's methodologies) begins with the threat model's specification and the attack surface's analysis.

Question 3

Distinguish the security policy from the security mechanism, and explain the reference monitor and its three properties. Why is the policy and the mechanism's distinction important?

Show answer

The security policy is the specification of what the system should allow: the subjects (the users, the processes), the objects (the files, the devices, the network's connections), and the operations (the reads, the writes, the executions) that are permitted. The policy is the system's requirements: it is determined by the stakeholders' needs, the law, and the organization's rules. The security mechanism is the specification of how the system enforces the policy: the access control's implementation (the permissions' checking, the capabilities, the mandatory access control), the authentication's protocols, and the auditing's machinery. The mechanism is the system's implementation: it is determined by the engineers' choices, and its correctness is verified by the code's audit and the testing. The reference monitor is the mechanism's abstract model, and it must satisfy three properties. It must be tamper-proof: the attacker cannot modify or bypass the reference monitor (it runs in the kernel's mode, and the user-mode's programs cannot modify its code or its data). It must be always invoked: every access to every object must be mediated by the reference monitor (the mechanism cannot be bypassed by an alternate path). It must be small enough to be verified: the reference monitor's code and its data structures must be small enough that their correctness can be established (the formal proof, the code's audit, the exhaustive testing). The policy and the mechanism's distinction is important because the two are independent, and the mechanism should enforce the policy without hard-coding it. The independence's rationale is the security's evolution: the policy changes (the organization's rules, the law, the users' needs) more often than the mechanism does, and a system whose mechanism hard-codes its policy must be rebuilt when the policy changes. The classical example is the access control's design: a system whose kernel hard-codes the "the owner can read, the others cannot" rule must be rebuilt when the organization adopts a different rule, while a system whose kernel enforces the policy's specification (the files' permission bits, the access control's lists, the capabilities) can accommodate the change by the policy's reconfiguration. The distinction is also the security's evaluation's basis: the mechanism's correctness can be verified independently of the policy's appropriateness, and the policy's appropriateness can be evaluated independently of the mechanism's correctness.

Question 4

Describe the Saltzer and Schroeder principles (the least privilege, the fail-safe defaults, the complete mediation, the open design, the separation of privilege, the least common mechanism, the psychological acceptability, and the economy of mechanism). What is each principle's rationale, and what is its application?

Show answer

The Saltzer and Schroeder principles are the eight design principles that the paper The Protection of Information in Computer Systems (1975) introduced. 1. The economy of mechanism: the security's mechanism should be as simple and as small as possible. Its rationale is the design's and the implementation's verifiability: a simple mechanism is easier to understand, to test, and to verify, and it has fewer bugs. Its application is the small reference monitor, the simple access control's model, and the minimal interfaces. 2. The fail-safe defaults: the access's decisions should be based on the permission's grant rather than the permission's denial — the default should be the denial. Its rationale is the errors' direction: a system that fails open grants the access when its policy is wrong or missing, while a system that fails closed denies the access when its policy is wrong or missing. Its application is the file systems' default permissions, the firewalls' default policies, and the authentication's defaults. 3. The complete mediation: every access to every object should be checked against the policy. Its rationale is the access's uniformity: a system that checks the access at the open time only can be bypassed by the file's replacement, and a system that checks the file's reads but not its memory maps can be bypassed by the mmap's use. Its application is the reference monitor's always-invoked's property and the modern systems' file's handles. 4. The open design: the security should not depend on the design's secrecy. Its rationale is the secrecy's fragility: a secret design leaks, and a system whose security depends on the secret's preservation collapses when the secret is revealed. Its application is the cryptographic algorithms' public scrutiny, the security protocols' open specifications, and the open-source's security. 5. The separation of privilege: the access should require more than one condition to be satisfied. Its rationale is the single-point's failure: a system whose access requires the password only can be compromised by the password's theft, while a system that requires the password and the hardware token can resist the password's theft alone. Its application is the multi-factor authentication, the two-person's rule, and the privilege's separation in the kernel. 6. The least privilege: every program and every user should operate with the minimum privileges necessary to complete the task. Its rationale is the damage's limitation: a program that runs with the administrator's privileges can damage the whole system when it is compromised, while a program that runs with the minimum privileges can damage only its own resources. Its application is the users' accounts, the services' accounts, the programs' capabilities, and the sandboxing. 7. The least common mechanism: the mechanism's sharing between the users should be minimized. Its rationale is the sharing's risks: the shared files, the shared memory, the shared caches, and the shared devices can leak the information and can be the denial of service's vectors. Its application is the per-process's address spaces, the per-user's temporary directories, and the resources' partitioning. 8. The psychological acceptability: the security's mechanism should be easy to use, and its interface should be intuitive. Its rationale is the users' behaviour: the security's mechanisms that the users find inconvenient are the mechanisms the users bypass, and the bypass's prevalence makes the mechanism ineffective. Its application is the single sign-on's designs, the biometrics' convenience, the password managers' use, and the security's defaults. The eight principles are the secure design's classical foundation, and the modern practice has extended them with the work factor, the compromise recording, and the least astonishment.

Question 5

Explain the defence in depth, the trusted computing base, and the AAA model. How does each relate to the operating system's security role?

Show answer

The defence in depth is the security's design strategy of the multiple, independent defences, so that the failure of one defence does not compromise the system. Its rationale is the defences' fallibility: no single defence is perfect, and a system that relies on a single defence is a system that fails when the defence fails. Its application is the layered design: the physical's security, the network's security, the host's security, the application's security, the data's security, and the people's security. The layers must be independent, and their failures must be uncorrelated: a system whose layers all depend on the same component has a single point of failure, and the layers' apparent redundancy is an illusion. The trusted computing base (TCB) is the set of the system's components that must be trusted for the security's policy to be enforced: the hardware, the kernel, and the privileged programs. The TCB's size is the security's central concern: the larger the TCB, the more the code must be verified, and the more the opportunities for the bugs and the flaws. The principle is the TCB's minimization, and it is the motivation for the microkernels and the hypervisors. The AAA model is the security's operational framework: the authentication (the verification of a subject's identity, with the factors of the knowledge, the possession, and the inherence), the authorization (the determination of what an authenticated subject is allowed to do, with the models of the DAC, the MAC, and the RBAC), and the accounting (the recording of the subjects' actions, with the purposes of the detection, the analysis, the deterrence, and the compliance). The three are the security's operational sequence: the subject is authenticated (who are you?), the subject is authorized (what can you do?), and the subject's actions are accounted (what did you do?). The three relate to the operating system's security role as follows. The defence in depth's host layer is the operating system's security's domain: the OS's hardening, the patches, the security modules, and the configuration are the host layer's defences. The TCB's core is the operating system's kernel: the reference monitor's implementation, the system calls' mediation, and the privileged operations' control are the kernel's TCB's components, and the kernel's size (the monolithic versus the microkernel) is the TCB's minimization's central decision. The AAA model's implementation is the operating system's security's core: the PAM's authentication, the permissions' and the capabilities' authorization, and the audit subsystem's accounting are the OS's implementation of the three pillars. The observation is the reason the operating system's security is the system's security's foundation: the OS's kernel is the TCB's core, its mechanisms are the AAA model's implementation, and its hardening is the defence in depth's host layer.

08 Unit discussion

Discussion prompt

The security's principles are the accumulation of nearly five decades of experience, and their history is a history of the lessons learned from the failures. The Saltzer and Schroeder paper (1975) codified the design principles after the early multi-user systems' failures: the systems that ran every program with the administrator's privileges, that trusted the users' inputs, and that relied on the design's secrecy. The principles were the response: the least privilege, the fail-safe defaults, the complete mediation, and the open design were the corrections of the specific failures, and their formulation was the security's first systematic design's guidance. The decades since have reinforced the principles: the Morris worm (1988) exploited the unnecessary services and the weak passwords; the Code Red and the Nimda (2001) exploited the unpatched servers and the default configurations; the Target and the Equifax breaches (2013 and 2017) exploited the third-party's access and the unpatched systems; and the ransomware's waves (the WannaCry and the NotPetya, 2017) exploited the unpatched systems and the flat networks. Each failure's lesson was the principle that the failure violated, and the principles' persistence is the evidence of their validity.

The principles' modern application is the zero trust architecture. The classical security's model was the perimeter's defence: the network's firewall protected the trusted interior, and the interior's systems trusted one another. The model's assumption was the perimeter's impermeability, and the modern attacks (the phishing, the supply chain, the insider, the remote work) invalidated the assumption: the attacker who breached the perimeter had the interior's trust, and the lateral movement was easy. The zero trust's model inverts the assumption: no user, no device, and no network is trusted by default, and every access is authenticated, authorized, and encrypted, regardless of the source. The model is the least privilege's and the complete mediation's principles applied at the architecture's scale: the per-request's authentication and authorization, the microsegmentation's network, and the continuous verification's monitoring.

The principles' future is being shaped by the artificial intelligence and the automation. The AI's systems (the machine learning's models, the large language models) introduce the new security's concerns: the models' poisoning (the training's data's corruption), the models' evasion (the inputs that fool the models), the models' extraction (the reconstruction of the training's data), and the models' misuse (the deepfakes, the disinformation). The automation's systems (the infrastructure as the code, the continuous deployment) introduce the new security's concerns: the configurations' drift, the dependencies' vulnerabilities, the secrets' management, and the supply chain's integrity. The classical principles still apply (the least privilege, the fail-safe defaults, the complete mediation), but their implementation is the new contexts' challenge, and the new threats' understanding is the security's ongoing work.

Which of the classical principles is the most important for the modern systems, and which is the most neglected? Should the security's design prioritize the users' convenience (the psychological acceptability) or the security's strictness, and who should make the trade-off's decision? How should the security's principles evolve for the AI's and the automation's systems? Post your response to the Unit 12 discussion forum and reply to at least two classmates. Supports CLO1, CLO7, and CLO8.

09 Practice exercise

This ungraded exercise consolidates the lesson and prepares you for Lesson 12.2. Aim to spend 60–90 minutes on it.

Analyze a security scenario. A hospital's patient-record system is being designed. The system holds the patients' medical records, the prescriptions, and the billing's information. The system's users are the doctors, the nurses, the pharmacists, the billing's staff, and the administrators. The system must comply with the health-privacy regulations.
- What are the system's assets?
- What are the threats (the natural, the accidental, the deliberate)?
- What are the vulnerabilities (the design, the implementation, the configuration, the users)?
- What are the attacks (the passive, the active, the local, the remote)?
- What is the threat model (the adversaries' capabilities, the resources, the goals)?
- How would you apply the Saltzer and Schroeder principles to the system's design?
Apply the principles. Choose a system you use (a web application, a mobile app, an operating system) and analyze its security's design through the eight principles. For each principle:
- Describe how the system applies the principle (or does not).
- Identify the principle's violations (if any).
- Suggest the improvements that the principle's application would provide.
Write a short report (500–750 words).
Analyze the attack surface. Use the Linux tools to inventory your VM's attack surface:
```
# The network's services
ss -tlnp
sudo ss -tlnup

# The running services
systemctl list-units --type=service --state=running

# The setuid programs
find / -perm -4000 -type f 2>/dev/null

# The capabilities
getcap -r / 2>/dev/null

# The kernel's modules
lsmod | head -20

# The users and their groups
cat /etc/passwd
cat /etc/group
```
Identify the attack surface's components and classify them by their necessity. Which components could be removed (the attack surface's reduction)? Which are the necessary? Write down your analysis.
Analyze the least privilege. Choose a program on your VM (a web server, a database, a system service) and analyze its privileges:
```
# Show the process's user and its groups
ps aux | grep <program>

# Show the process's capabilities
sudo getpcaps <pid> 2>/dev/null

# Show the program's setuid bit
ls -la $(which <program>)

# Show the program's open files and its network's connections
sudo lsof -p <pid> 2>/dev/null | head -20
sudo ss -tnp | grep <pid>
```
What are the program's privileges? Does it run with the least privilege? What are the unnecessary privileges? How would you reduce them (the dedicated user, the capabilities, the sandboxing)?
Analyze a security breach. Choose a known security breach (the Equifax, the Target, the WannaCry, the SolarWinds) and analyze it through the lesson's principles. Write a short report (500–750 words) that addresses:
- The breach's timeline and its stages.
- The vulnerabilities that the attackers exploited.
- The principles that the organization violated.
- The defences that the principles would have provided.
- The lessons for the security's design.
Design a security policy. A small business is setting up a Linux server for its file sharing and its email. The server holds the employees' documents, the customers' information, and the business's financial records. Design the server's security policy:
- The users' accounts and their privileges.
- The files' permissions and their ownership.
- The services and the network's configuration.
- The authentication's mechanisms.
- The auditing's configuration.
- The backups' strategy.
- The incidents' response's plan.
Justify your design through the Saltzer and Schroeder principles.
Compare the defence in depth's layers. Write a short paragraph (200–250 words) comparing the defence in depth's layers (the physical, the network, the host, the application, the data, and the people). Your paragraph should address:
- Each layer's mechanisms.
- Each layer's threats.
- The layers' interdependence (the independence's importance).
- The layers' relative costs and their effectiveness.
- The layers' priorities for the different systems (a personal laptop, a web server, a hospital's system).
Reflect. In your own words, explain the security's goals (the CIA triad) and the design principles (the Saltzer and Schroeder's eight). Then describe one situation in your own experience — a system you have used or a service you have relied on — where the security's principles mattered. What was the system, and how did the principles' application (or violation) affect the outcome?

10 Summary

The security's goals are the CIA triad: the confidentiality (the data is disclosed only to the authorized parties), the integrity (the data is modified only by the authorized parties), and the availability (the resources are available to the authorized parties). The modern security also includes the authenticity, the accountability, the non-repudiation, and the privacy.
The security's chain is the threat (a potential cause of an unwanted incident), the vulnerability (a weakness that a threat could exploit), and the attack (the exploitation of a vulnerability). The threat model is the specification of the threats, and the attack surface is the set of the components that an attacker can interact with.
The security policy is the specification of what the system should allow, and the security mechanism is the specification of how the system enforces the policy. The two are independent, and the mechanism should enforce the policy without hard-coding it. The reference monitor is the mechanism's abstract model, and it must be tamper-proof, always invoked, and small enough to verify.
The Saltzer and Schroeder principles are the secure design's classical foundation: the economy of mechanism, the fail-safe defaults, the complete mediation, the open design, the separation of privilege, the least privilege, the least common mechanism, and the psychological acceptability. The modern practice has extended them with the work factor, the compromise recording, and the least astonishment.
The defence in depth is the strategy of the multiple, independent defences: the physical, the network, the host, the application, the data, and the people. The layers must be independent, and their failures must be uncorrelated. The trusted computing base (TCB) is the set of the components that must be trusted, and its minimization is the microkernels' and the hypervisors' motivation.
The AAA model is the security's operational framework: the authentication (the identity's verification, with the factors of the knowledge, the possession, and the inherence), the authorization (the permissions' determination, with the models of the DAC, the MAC, and the RBAC), and the accounting (the actions' recording, with the purposes of the detection, the analysis, the deterrence, and the compliance).
The operating system's security role is the mediation of the resources' accesses: the processes' isolation, the files' protection, the authentication's enforcement, the privileged operations' control, the auditing, and the security's boundaries. The OS's kernel is the reference monitor, and its security is the foundation on which the applications' security builds.

Looking ahead

This lesson presented the security's principles: the CIA triad, the threats and the vulnerabilities and the attacks, the threat models and the attack surfaces, the policy and the mechanism, the reference monitor, the Saltzer and Schroeder principles, the defence in depth, the trusted computing base, and the AAA model. It referred several times to the authentication — the identity's verification, the first pillar of the AAA model — and to the authorization and the access control. Lesson 12.2 presents authentication in detail: the factors (the knowledge, the possession, the inherence), the password's mechanisms and their weaknesses, the challenge-response's protocols, the biometrics, the multi-factor authentication, the single sign-on, and the authentication's protocols (the Kerberos, the RADIUS, the OAuth). The lesson is the second pillar of the unit's presentation of the operating system's security, and it is the foundation for the authorization and the access control that the following lessons present.

11 References

Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 16, Sections 16.1–16.3.
Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, the Security chapters. Available online at ostep.org.
Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapter 9, Sections 9.1–9.3.
Saltzer, J. H., & Schroeder, M. D. The Protection of Information in Computer Systems. Proceedings of the IEEE, 1975.
Anderson, R. Security Engineering, 2nd ed. Wiley, 2008.
Bishop, M. Computer Security: Art and Science, 2nd ed. Addison-Wesley, 2019.
NIST SP 800-160. Systems Security Engineering. National Institute of Standards and Technology.
Linux man-pages: man 7 capabilities, man 7 credentials, man 5 passwd, man 5 shadow, man 5 sudoers, man 8 sudo, man 1 id, man 8 setcap, man 1 getcap, man 1 chmod, man 1 chown, man 8 auditctl, man 8 ausearch, man 1 last, man 1 lastlog, man 8 selinux, man 8 apparmor.