FIT2100 Chap.12 Operating System Security
Operating System Security
Operating-system security layers authentication, authorisation, isolation, auditing and maintenance around valuable resources. Authentication establishes an identity. Authorisation determines what that identity may do. Privilege modes and address spaces prevent ordinary code from directly controlling the kernel or another process. Access-control models record rights to objects.
Threat analysis should be causal.
Name the asset, entry point, broken assumption, failed control and consequence before proposing a repair. Malware labels alone do not explain how protection was bypassed. Least privilege, input validation, safe defaults, patching and simplified interfaces reduce exposure. Complexity and obsolete compatibility paths expand the trusted surface that defenders must understand.
What this chapter covers
- 01
Security goals
- 02
Authentication
- 03
Authorisation
- 04
Access control
- 05
Memory protection
- 06
Malicious software
- 07
Design flaws
- 08
Maintenance and lifecycle
Worked example · free
Analyse an over-privileged helper
- +2The asset is any file the privileged helper can modify, and the untrusted path argument is the entry point.
- +2Validation and confinement fail because the caller can select an object outside the intended directory while the helper retains broad authority.
- +2Canonicalise and constrain the target, reduce privilege, reject traversal, log attempts and test both accepted and rejected cases.
Key terms
- Authentication
- The process of establishing or verifying the identity associated with a request.
- Authorisation
- The decision about whether an authenticated identity may perform a requested operation on an object.
- Least Privilege
- The principle of granting only the authority required for a task and no broader access.
- Access Control
- The mechanisms and policy records used to permit or deny operations on protected objects.
- Attack Surface
- The set of reachable interfaces and behaviours through which an attacker may influence a system.
- Defence in Depth
- The use of several independent protective layers so one failure does not expose the entire system.
Operating System Security FAQ
How are authentication and authorisation different?
Authentication supplies evidence about who is acting. Authorisation checks whether that identity has the requested right over a particular object. A valid login does not imply unrestricted file or kernel access.
Why does least privilege reduce risk?
A flaw or compromised component can affect only the resources available to its narrow authority. Broad administrative execution turns a small input or memory defect into a system-wide consequence.
Why can more security features increase exposure?
A feature may add privileged code, parsers, configuration and interactions that create new defects or weaken old assumptions. Security evaluation must consider the extra trusted surface as well as the intended protection.
What makes a strong threat explanation?
It traces a specific asset through an entry point and broken assumption to a failed control and consequence. The repair then targets that mechanism with validation, reduced privilege, isolation, monitoring or timely maintenance.
How should I test a proposed security repair?
State the exact subject, protected object and requested operation before testing. Run a permitted normal case, a boundary case and a malicious case designed to exercise the failed assumption. Verify not only the returned message but also that protected state remains unchanged after rejection. Repeat under the process identity and privilege set the deployed component will actually use.
Then assume the new validation contains a flaw and ask which independent control limits damage: restricted permissions, address-space isolation, a narrow capability, safe defaults or protected audit records. Check cleanup and logging for both success and failure without exposing sensitive data. A repair is stronger when it removes unnecessary authority or an obsolete path, because that reduces what must remain correct.
Document the causal link from the original entry point to the control that now stops it; a generic claim that the system is secure is not evidence. This method tests enforcement, containment and observability as separate properties.
Assessment move
Organise security cases by boundary rather than attack name. For each scenario, identify identity, requested operation, protected object, authority check and isolation layer. Practise turning vague labels into causal chains and propose repairs that include least privilege. In demonstrations, show a rejected malicious input as well as the normal case and state the process identity.
Review system complexity as a design risk: every privileged interface and legacy path adds assumptions that require testing and maintenance. Use a six-part worksheet for every case: asset, entry point, trust transition, failed assumption, consequence and enforced repair. Add the subject identity, requested operation and object so authentication is never confused with authorisation.
For file examples, evaluate directory traversal authority separately from permissions on the final file. For privileged helpers, list every capability they truly need and remove unrelated authority before considering input filtering. Trace untrusted data through parsing, canonicalisation and object selection, then mark the last point at which rejection remains safe.
Compare preventive controls with audit evidence: validation and access checks stop actions, while protected logs help detect and reconstruct them. Test whether a proposed repair still contains damage if one other layer fails; that is the practical meaning of defence in depth. Review a legacy or compatibility path by drawing the complete authority route and asking whether it bypasses a newer control.
In a demonstration, run an accepted boundary case, a rejected malicious case and a cleanup check under the stated process identity. Do not treat one rejection message as proof of total security. Explain exactly which control fired, what state remained unchanged and what independent layer would limit impact if that check were flawed.
Working through Operating System Security in FIT2100? Sia is AskSia’s AI Computer Science tutor — ask any FIT2100 Operating System Security question and get a clear, step-by-step explanation grounded in how FIT2100 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
