Before the questions, make sure you can: distinguish protection mechanisms from security policies and state the CIA goals; apply the principle of least privilege; represent rights with an access matrix and derive ACLs and capability lists; read and compute Unix permissions (symbolic and octal), apply a umask and decide whether an access is allowed; explain setuid and Linux capabilities; apply Bell–LaPadula and Biba rules; compute password search spaces and explain why salts and slow hashes matter; describe how canaries, NX and ASLR defend against memory-corruption attacks; explain sandboxing, secure boot and TEEs; and build a threat model for an edge–cloud system.
An operating system is a reference monitor: every access by a process to a file, a device, memory or the network passes through the kernel, which decides whether it is allowed. Protection is the set of mechanisms that enforce these decisions; security is the broader goal of keeping the system's confidentiality, integrity and availability against attackers who are clever, patient and often inside the network. Edge computing makes security harder: servers sit in closets and on lamp posts, not in guarded data centers, and every phone is a potential entry point.
Goals and principles
- Confidentiality — only authorized parties read data. Integrity — only authorized parties modify it. Availability — the service works when needed (the CIA triad).
- Least privilege — each process, user or service gets only the rights it needs, only while it needs them. It limits the damage of any compromise (a hacked web server should not be able to read the password database).
- Defense in depth — several independent layers (firewall, authentication, permissions, sandbox, monitoring).
- Separate policy from mechanism — the kernel provides mechanisms (permission bits, capabilities, namespaces); administrators define policies.
The access matrix
A protection domain is a set of (object, rights) pairs — typically a user or process. The access matrix has domains as rows, objects as columns and rights in the cells. It is sparse, so it is stored in one of two ways:
- Access control lists (ACLs) — per object (column): "report: alice rwo, bob r". Easy to answer "who can access this file?" and to revoke. Used by file systems (Unix permissions are a compressed ACL; NTFS and ext4 support full ACLs).
- Capability lists — per domain (row): "bob: data rwo, report r". A capability is an unforgeable token; possessing it grants access. Easy to delegate and check, harder to revoke. Used by file descriptors (once opened, the descriptor is a capability), cloud tokens (signed URLs, OAuth tokens) and capability-based OSs (seL4, Fuchsia).
Only the owner (right o) may grant or revoke rights in the lab model — a simple form of discretionary access control (DAC).
Unix permissions
Each file has an owner, a group and 9 bits: rwx for the owner, the group and others. Octal: r = 4, w = 2, x = 1 → rwxr-xr-- = 754; rw-r----- = 640.
The kernel checks one class only: if you are the owner, the owner bits decide (even if "others" have more rights!); else if you belong to the file's group, the group bits; else the others bits. A file with mode 044 cannot be read by its owner. For directories, r = list names, w = create/delete entries, x = enter/traverse.
umask removes bits from new files: files start from 666, directories from 777. umask 022 → files 644, directories 755; umask 027 → directories 750; umask 077 → files 600 (private).
root (UID 0) bypasses read/write checks (but can execute a file only if some x bit is set). setuid programs (e.g., passwd, mode 4755) run with the owner's identity — powerful and dangerous: a bug in a setuid-root program is a privilege escalation. Modern Linux splits root's power into capabilities (CAP_NET_BIND_SERVICE to use port 80, CAP_SYS_ADMIN, …) so a program can receive only the one it needs — least privilege again.
Mandatory access control
With DAC, owners decide. With MAC, a system-wide policy decides, and users cannot override it.
- Bell–LaPadula (confidentiality, military origin): levels Public < Confidential < Secret. No read up (a Confidential analyst cannot read Secret exams) and no write down (the analyst cannot write into a Public brochure — no leaking secrets downward).
- Biba (integrity): the dual. No read down (a System installer should not read Untrusted downloads and act on them) and no write up (an Untrusted browser cannot modify System files).
- SELinux (Android, Red Hat) and AppArmor (Ubuntu) implement MAC in Linux: even a root process confined to the "web server" domain can only access what the policy allows. Windows' integrity levels apply Biba-like rules to browsers.
Authentication
Before authorizing, the OS must know who you are: something you know (password), have (phone, security key) or are (fingerprint).
Passwords are stored hashed, never in plain text, each with a random salt (so identical passwords have different hashes and precomputed tables are useless) and with a deliberately slow hash (bcrypt, scrypt, Argon2). Consider an attacker who stole the hash database (offline attack) and computes 10¹⁰ fast hashes/s (MD5 on GPUs) or 10⁴ bcrypt (cost 12) hashes/s:
| Password | Search space | Bits | Average time (fast hash) | Average time (bcrypt) |
|---|---|---|---|---|
| 8 lowercase letters | 26⁸ ≈ 2.1 × 10¹¹ | 37.6 | 10 s | 121 days |
| 8 mixed letters/digits | 62⁸ ≈ 2.2 × 10¹⁴ | 47.6 | 3 hours | 346 years |
| 4 random words (7,776-word list) | 7,776⁴ ≈ 3.7 × 10¹⁵ | 51.7 | 2.1 days | 5,793 years |
| 12 random printable chars | 94¹² ≈ 4.8 × 10²³ | 78.7 | 754,050 years | ≈ 7.5 × 10¹¹ years |
Length and slow hashing matter more than complexity rules; human-chosen passwords are far weaker than random ones (dictionaries). Multi-factor authentication and passkeys (public-key credentials bound to a device) remove most of the risk of stolen passwords.
Attacks on programs and OS defenses
- Buffer overflows in memory-unsafe code (C/C++) can overwrite a function's return address or data. Defenses built into compilers and OSs: stack canaries (a random value checked before returning), NX / DEP (data pages are not executable — enforced by a page-table bit, Chapter 9), ASLR (random placement of stack, heap and libraries, so addresses are unpredictable), and memory-safe languages (Java, Rust, Go), which remove whole classes of bugs.
- Privilege escalation — exploiting a bug in the kernel or a privileged program to gain root. Defense: patching, least privilege, MAC, sandboxing.
- Malware and ransomware — ransomware encrypts files and demands payment; defense: least privilege, patching, and offline/immutable backups (Chapter 11: RAID is not a backup).
- Denial of service — exhausting CPU, memory, connections or bandwidth; defense: quotas and limits (cgroups, Chapter 12), rate limiting, autoscaling.
- Supply-chain attacks — malicious code in dependencies or build systems; defense: signed packages, software bills of materials (SBOMs), reproducible builds.
Isolation and trust
- Sandboxing: processes, VMs and containers (Chapter 12) isolate code; seccomp filters limit which system calls a process may make (Docker blocks ~40 dangerous syscalls by default; Chrome's renderer processes are heavily sandboxed).
- Secure boot: each stage of the boot (firmware → bootloader → kernel) verifies the signature of the next; a TPM chip measures and attests the boot state — essential for edge servers that attackers can touch.
- Encryption: in transit (TLS everywhere, including inside the data center) and at rest (disk encryption, so a stolen edge disk reveals nothing).
- Trusted execution environments (Intel SGX/TDX, AMD SEV, ARM TrustZone) protect code and data even from a compromised OS or cloud operator — confidential computing.
Security at the edge and in the cloud
Edge servers are physically exposed, numerous and hard to update; phones and IoT devices are often weakly protected. Modern practice is zero trust: never trust a request because it comes from "inside" the network — authenticate and authorize every request (mutual TLS between services, short-lived tokens), give each service a minimal identity and permissions (Kubernetes RBAC, network policies), encrypt everything, update automatically (signed over-the-air updates), and monitor (audit logs, anomaly detection). Offloading decisions (Chapter 13) must also respect security: sensitive data may be allowed on the campus edge but not in a public cloud region.
Most real breaches do not break cryptography — they exploit weak or reused passwords, unpatched software, over-privileged accounts and misconfigured cloud storage (public buckets). The OS concepts of this chapter — least privilege, authentication, patching and isolation — are exactly the controls that stop them.
Security adds constraints and costs to scheduling and offloading research: encrypting data adds computation and latency, TEEs reduce performance and memory, and trust levels restrict where tasks may run. Security-aware scheduling in edge–cloud systems treats these as part of the optimization problem — for example, placing sensitive workflow tasks only on trusted nodes while minimizing makespan and energy.
Key takeaways
- CIA goals; protection = mechanisms, security = goal against attackers; least privilege and defense in depth.
- Access matrix → ACLs (per object, easy revocation) or capabilities (per domain, easy delegation).
- Unix: rwx for owner/group/others, octal (754, 640), one class is checked; umask (022 → 644/755); root, setuid, Linux capabilities.
- MAC: Bell–LaPadula (no read up, no write down) for confidentiality; Biba (no read down, no write up) for integrity; SELinux/AppArmor.
- Passwords: salted, slow hashes; search space = alphabet^length; length + MFA/passkeys.
- Defenses: canaries, NX, ASLR, memory-safe languages, sandboxing/seccomp, secure boot + TPM, encryption, TEEs.
- Edge/cloud: zero trust, signed updates, least-privilege identities, monitoring, security-aware placement.
Ready? Close the notes and practise.
30 questions. Predict the output before you check — that is the skill the exam measures.