OS Security: Threats, Policy Mechanism, Protection, Trusted Systems, Authentication & Windows Security

1. Security vs Protection in Operating Systems

Students often use the words Protection and Security interchangeably, but in Operating Systems they have distinct meanings:

Protection (Internal Defense): Any mechanism that controls the access of internal processes and users to the resources defined by the computer system (e.g., preventing Process A from overwriting Process B’s RAM or deleting another user’s file).
Security (External & Overall Defense): Defending the system against external and internal malicious attacks (viruses, hackers, unauthorized logins) to preserve the CIA Triad:
1. Confidentiality (Only authorized users can read data)
2. Integrity (Only authorized users can modify data)
3. Availability (System remains accessible to authorized users without DoS crashes)

2. OS Security Threats (Program Threats vs System/Network Threats)

Security threats to an Operating System are classified into two major categories:

Figure 5.9: Classification of Operating System Security Threats

1. Program Threats (Malicious Code)

Trojan Horse: Fake useful app that secretly steals data or installs spyware
Trap Door (Backdoor): Secret undocumented entry point left by a programmer to bypass login
Logic Bomb: Malicious code that triggers only when a specific date or condition occurs
Virus: Self-replicating code that attaches itself to legitimate `.exe` files

2. System & Network Threats

Worms: Standalone malware that replicates across networks automatically without human action
Port Scanning: Automated probing of a server's TCP/UDP ports to find weak services
Denial of Service (DoS): Flooding a system with fake requests so legitimate users are locked out

3. Security Policy vs Security Mechanism

A fundamental design principle of Operating Systems is the Separation of Policy and Mechanism:

Basis	Security Policy (“WHAT” is to be done)	Security Mechanism (“HOW” it is enforced)
1. Definition	A high-level rule or decision specifying WHAT is allowed and who is authorized to access which resource.	The low-level technical tool, algorithm, or hardware feature that enforces the security policy.
2. Question Answered	Answers “WHAT” needs to be protected and from whom.	Answers “HOW” the protection will be implemented.
3. Who Decides It?	Decided by the System Administrator / Organization Management.	Built into the Operating System Kernel by OS developers.
4. Real-Life Example	Policy: “Only BCA Faculty can edit marksheets; students can only view them.”	Mechanism: Passwords, Access Control Lists (ACLs), Encryption, and File Permission Bits (`rwx`).

4. Protection in OS: Domains of Protection & Access Matrix

How does the OS enforce internal Protection? Using the Principle of Least Privilege (every program and user should be given only the bare minimum privileges needed to perform its task) and the Access Matrix Model.

A. Protection Domain

A computer system is a collection of Processes and Objects (hardware objects like CPU, RAM, Printers, and software objects like Files, Semaphores).
A Protection Domain is a set of <Object, Rights-Set> pairs that specifies which objects a process can access and what operations (Read, Write, Execute) it can perform on them.

B. The Access Matrix Model

The general model of protection is viewed abstractly as a 2D table called an Access Matrix:

Rows represent Domains (Users / Roles) (D1, D2, D3).
Columns represent Objects (Files / Devices) (F1, F2, Printer).
Cell Access(i, j) defines the exact set of operations that a process executing in Domain Di can invoke on Object Oj!

Domain (User/Role)	File `Notes.pdf`	File `Marks.db`	`LaserPrinter`
D1 (Student)	`Read`	(No Access)	`Print`
D2 (Faculty)	`Read, Write`	`Read, Write`	`Print`
D3 (Admin)	`Read, Write, Delete`	`Read, Write, Execute`	`Print, Configure`

How the Access Matrix is Implemented in Real OS:

Access Control Lists (ACLs — Column-Wise): Attached to each File/Object is a list of users and their permissions for that file (used in Windows NTFS).
Capability Lists (Row-Wise): Attached to each User/Domain is a list of unforgeable “tickets” (capabilities) listing the objects they are allowed to access.

5. Trusted Systems, User Authentication & Internal Access Authorization

A. Trusted Systems (Trusted Computing Base — TCB)

A Trusted System is a hardware and software system that has been rigorously verified and certified to enforce a strict Multilevel Security Policy (such as military classifications: Top Secret > Secret > Confidential > Unclassified).
At the core of a Trusted System is the TCB (Trusted Computing Base) and a tamper-proof Reference Monitor that mediates every single access request to ensure a lower-clearance user can never read higher-classification data (Bell-LaPadula “No Read Up, No Write Down” Model).

B. User Authentication (Verifying “Who You Are”)

Before the OS grants any permissions, it must verify the identity of the user logging in (Authentication) based on three factors:

Something the User KNOWS: Passwords, PINs, Passphrases (stored on disk as one-way Salted Cryptographic Hashes, never in plain text!).
Something the User HAS: Smart Cards, Hardware Security Keys (YubiKey), Mobile OTP token.
Something the User IS (Biometrics): Fingerprint scanner, Face ID / Iris scan, Voice recognition.

C. Internal Access Authorization (Controlling “What You Can Do”)

Once a user is authenticated, Internal Access Authorization determines which internal system files, memory segments, and devices that user’s processes are permitted to touch—enforced via User IDs (UID), Group IDs (GID), permission bits (rwxr-xr--), and Access Tokens.

6. Windows Security Architecture (Windows NT / 10 / 11)

Your DAVV Unit 5 syllabus explicitly includes Windows Security! Modern Microsoft Windows uses a robust, object-based security model built around four core components:

Figure 5.10: How Windows Security Architecture Works

1. Winlogon & LSASSVerifies User Login & Password against SAM / Active Directory

→ Generates →

2. Access Token (SID)Attached to every process launched by that User

→ Checked by →

3. SRM (Security Reference Monitor)Compares User's Token against the File's ACL (Security Descriptor)

SID (Security Identifier): Every user account and group in Windows is assigned a globally unique, immutable ID called a SID (e.g., S-1-5-21-...). Even if you delete an account named "Rohan" and create a new account named "Rohan", the new account gets a completely different SID!
LSASS (Local Security Authority Subsystem Service) & Access Token: When a user logs into Windows, LSASS verifies their credentials against the SAM (Security Accounts Manager) database and creates a Security Access Token containing the user’s SID, group SIDs, and privileges. Every process started by that user inherits a copy of this Access Token.
Security Descriptor (DACL & SACL) on NTFS Objects: Every file, folder, registry key, and printer in Windows has a Security Descriptor containing two lists:
- DACL (Discretionary Access Control List): Specifies which users/SIDs are allowed or denied access (Full Control, Modify, Read & Execute, Write).
- SACL (System Access Control List): Controls security auditing and event logging when someone tries to access the file.
SRM (Security Reference Monitor): A kernel-mode component that acts as the ultimate gatekeeper: whenever a process tries to open a file, the SRM compares the process’s Access Token against the file’s DACL and grants or denies access.

💡 Exam Preparation Tips for DAVV BCA

Always include the Access Matrix Table and the Security Policy (“WHAT”) vs Security Mechanism (“HOW”) comparison table when answering Unit 5 Security questions!
For Windows Security, remember the 4 acronyms: SID (Security Identifier), LSASS (Login authority that creates the Access Token), DACL (Access Control List on NTFS files), and SRM (Security Reference Monitor in Kernel).

OS Security: Security Threats, Policy vs Mechanism, Protection, Trusted Systems, Authentication & Windows Security