UNIT 4: OS INTERNALS FOR SECURITY SUPPORT - EXAM-FOCUSED NOTES

I. CORE OS STRUCTURES & MEMORY MANAGEMENT

Buffer Cache & Buffer Management

• Role & Purpose: A region in main memory that stores copies of disk blocks to reduce frequent, slow disk I/O operations. Improves performance via temporal locality (recently used blocks likely reused) and spatial locality (blocks near a recently used block likely needed).

• Buffer Header Structure: Metadata attached to each buffer frame in the pool.

  [!TIP] Common exam diagram: Sketch showing DEVICE NO. | BLOCK NO. | STATUS BITS | DATA POINTER.

  • Device Number: Disk/device identifier.

  • Block Number: Corresponding disk block number.

  • Status Bits: Flags (e.g., VALID, DIRTY, BUSY, LOCKED).

  • Data Pointer: Points to actual data in buffer pool.

  • Queue Pointers: Links for free, device, and hash queues.

• Buffer Pool Organization: Managed via three queues:

  1. Free List: Buffers available for allocation.

  2. Device Queues: Buffers with data for a specific device waiting for I/O completion.

  3. Hash Queue: Buffers indexed by (device, block number) for fast lookup (avoids linear search).

  Algorithm: getblk(dev, blkno) searches hash queue; if not found & free list empty, may delay or flush a dirty buffer.

• Relationship with File System I/O: File system reads/writes first check buffer cache (cache hit = fast memory access; cache miss = disk I/O). Write-back caching (DIRTY bit) delays writes.

File System Metadata & Kernel Structures

• Super Block (UNIX): In-memory/disk structure storing global file system metadata.

  • Contents: File system size, free block count & list, inode count & free list, magic number, block size, modification timestamp.

  • Function: Mounting uses it to verify file system integrity; updates track space allocation.

• UNIX OS Components & Features:

  • Kernel: Core, manages hardware/resources (processes, memory, I/O, security).

  • Shell: Command interpreter (user-kernel interface).

  • File System: Hierarchical, everything is a file (devices, processes).

  • Processes: Lightweight, created via fork(); exec() replaces image.

  • Pipes/IPC: Unidirectional byte streams.

  • Security: User/group IDs, permission bits (rwx).

• Kernel Role & Architecture:

  • Role: Ultimate resource manager, mediator between hardware and applications. Enforces security policies.

  • Architecture: Monolithic (traditional UNIX) vs. Microkernel (minimal core, services as user processes). Modern kernels (Linux, Windows NT) hybrid.

• Key System Calls:

  • open(path, flags): Returns file descriptor; checks permissions.

  • read(fd, buf, n): Reads n bytes from file fd to buf.

  • create(path, mode): Creates new file with permissions mode.

  • chmod(path, mode): Changes file permission bits.

II. PROCESS MANAGEMENT & SCHEDULING

Process Life Cycle & Control

• Life Cycle States:

  1. New: Process created (OS allocates PCB).

  2. Ready: In main memory, waiting for CPU.

  3. Running: Executing on CPU.

  4. Waiting/Blocked: Waiting for event (I/O, signal).

  5. Terminated: Process ended; PCB may be kept for exit status.

  Transitions: New→Ready (admitted), Ready→Running (scheduled), Running→Ready (preempted), Running→Waiting (I/O request), Waiting→Ready (I/O complete), Running→Terminated (exit).

• Process Control Block (PCB): OS data structure containing all process info for management.

  • Components:

    • Process State (ready, running, etc.)

    • Process ID (PID)

    • Program Counter (PC)

    • CPU Registers (saved during context switch)

    • CPU Scheduling Info (priority, scheduling queue pointers)

    • Memory Management Info (base/limit, page tables)

    • Accounting Info (CPU time used, limits)

    • I/O Status Info (open files, allocated I/O devices)

Process Scheduling

• Objectives: Maximize CPU utilization/throughput, minimize turnaround/waiting/response time, fairness, balance resource use.

• Types of Algorithms:

  • Non-Preemptive: FCFS, SJF (Shortest Job First), Priority Scheduling.

  • Preemptive: Round Robin (RR), Shortest Remaining Time First (SRTF), Priority with preemption.

  Key Formula: Average Waiting Time = $$\displaystyle \frac{\sum \text{Waiting Time of all processes}}{\text{Number of processes}} $$.

• Context Switching: Saving state of current process (PCB, registers) to memory and loading state of next process. Overhead—pure CPU time lost; minimized by efficient PCB storage (e.g., kernel stack).

III. CONCURRENCY, SYNCHRONIZATION & IPC

Principles of Concurrency

• Requirements: Multiple processes/threads in system, shared resources (memory, files, devices), independent execution but potential interaction.

• Challenges:

  • Race Condition: Multiple processes access shared data concurrently, outcome depends on execution order.

  • Critical Section: Code segment accessing shared resource. Must satisfy:

    1. Mutual Exclusion: Only one process in CS at a time.

    2. Progress: If no process in CS & processes wish to enter, decision in finite time.

    3. Bounded Wait: Finite wait before entering CS.

    4. No Assumption on Hardware Speed.

  • Deadlock: Circular wait for resources (mutual exclusion, hold-and-wait, no preemption, circular wait).

  • Starvation: Process perpetually denied resource.

Synchronization Mechanisms

• Semaphore: Integer variable used for signaling, accessed via atomic wait() (P) and signal() (V) operations.

  
  wait(S) {
  
      while (S <= 0); // busy wait
  
      S--;
  
  }
  
  signal(S) {
  
      S++;
  
  }
  
  

• Types:

  • Binary Semaphore (Mutex): Values 0 or 1. Used for mutual exclusion. Initial value 1.

    Example: Protecting a critical section.

  • Counting Semaphore: Integer ≥ 0. Tracks count of available resources. Initial value = number of identical resources.

    Example: Managing n identical I/O devices.

Inter-Process Communication (IPC)

• Overview of Methods:

  • Shared Memory: Fastest; processes attach to common memory region. Requires synchronization (semaphores).

  • Message Queues: Kernel-managed message links; processes send/receive messages.

  • Pipes: Unidirectional byte stream (anonymous for parent-child, named for unrelated).

  • Sockets: Network-endpoint communication (local or network).

• Detailed Example: Shared Memory IPC:

  1. Creation: shmget(key, size, IPC_CREAT | 0666) returns shmid.

  2. Attachment: shmat(shmid, NULL, 0) returns pointer to segment.

  3. Synchronization: Use semaphores to protect access.

  4. Detachment: shmdt(ptr).

  5. Control/Deletion: shmctl(shmid, IPC_RMID, NULL).

  Client-Server: Server creates/attaches, client attaches using same key/shmid. Data written by server read by client.

• Socket-based IPC:

  • Socket Concept: Endpoint for communication, identified by IP + port (or path for Unix domain).

  • Types:

    • Stream (SOCK_STREAM): TCP, connection-oriented, reliable, byte-stream.

    • Datagram (SOCK_DGRAM): UDP, connectionless, message-preserving boundaries, unreliable.

  • Client-Server Model:

    1. Server: socket() → bind() → listen() → accept() → read()/write().

    2. Client: socket() → connect() → write()/read().

IV. FILE SYSTEM MANAGEMENT

File System Operations

• Mounting: Attaching a file system (on a device) to the system's directory tree at a mount point.

  • Process: mount(dev, dir, type, options); kernel reads super block of dev, integrates into VFS (Virtual File System) tree.

  • Advantages: Seamless access, unified namespace, security checks at mount point.

  • Disadvantages: Single point of failure (if mount point corrupted), need unmount before removal.

• Unmounting: Detaching file system; ensures no open files, writes back cached data.

  • umount(dir): Flushes buffers, updates super block, removes from VFS.

Data Structures in OS

• Queue:

  • Applications:

    • Ready Queue: Processes ready for CPU (scheduling).

    • Device Queues: Processes waiting for I/O device.

    • Job Queue: All processes in system.

    • Message Queues: IPC (as above).

  • Operations: enqueue(), dequeue(); often circular for efficiency.

• Tree:

  • Applications:

    • Directory Structure: Hierarchical (tree) organization of files. Root directory, subdirectories, files as leaves.

    • Process Tree: Parent-child relationships (fork() creates child).

    • Memory Management: Page tables (multi-level), segment trees.

  • Advantages: Efficient lookup, natural hierarchy, access control inheritance.

V. SECURITY & PROTECTION FUNDAMENTALS

Core Security Mechanisms

• Implementation in OS:

  • Access Control: Enforce policies on resource access (files, memory, devices).

  • Authentication: Verify user identity (passwords, biometrics, tokens).

  • Authorization: Define what authenticated user can do (permissions, ACLs).

  • Auditing: Log security-relevant events (login, file access).

  • Cryptography: For secure storage (encrypted files) and communication (TLS).

• Authentication Models:

  • Something you know: Password, PIN.

  • Something you have: Smart card, token.

  • Something you are: Biometric (fingerprint, iris).

  • Multi-Factor Authentication (MFA): Combination.

• Access Control Models:

  • Discretionary Access Control (DAC): Owner decides permissions (UNIX rwx bits). Flexible but vulnerable to Trojan.

  • Mandatory Access Control (MAC): System-enforced policies based on security labels (e.g., military: Top Secret, Secret). Rigid, prevents info flow leaks.

  • Role-Based Access Control (RBAC): Permissions assigned to roles, users assigned roles. Scalable for enterprises.

Vulnerabilities & Threats

• Common Vulnerabilities and Exposures (CVEs): Publicly known cybersecurity flaws (e.g., buffer overflow, SQL injection, misconfiguration). Cataloged by MITRE; used to prioritize patches.

• Honeypot: Decoy system/app designed to attract attackers.

  • Use: Detect intrusion attempts, study attacker tactics/techniques, divert from real assets, gather threat intelligence.

  • Types: Low-interaction (simulated services) vs. High-interaction (real OS).

Virtualization for Security

• Techniques:

  • Full Virtualization: VM runs unmodified OS; hypervisor (Type-1: bare-metal, Type-2: hosted) provides isolation. Security: Malware confined to VM; snapshots for forensics.

  • Paravirtualization: Guest OS modified for better performance; still isolated.

  • Containerization (OS-level): Processes isolated via namespaces/cgroups (e.g., Docker). Security: Less isolation than VM but lightweight; escape vulnerabilities critical.

  • Sandboxing: Restrict process capabilities (e.g., seccomp in Linux, AppContainer in Windows).

VI. MALWARE, THREATS & ATTACK VECTORS

Malware Taxonomy & Definitions

• Malware: Malicious software designed to harm, steal, or gain unauthorized access.

• Trojan: Disguised as legitimate software; does not self-replicate. Purpose: Backdoor, data theft, ransomware delivery.

• Rootkit: Hides existence/activity of malware; modifies OS/kernel. Stealth: Conceals processes/files/network connections.

• Viruses: Attach to legitimate programs; require user execution to spread.

  • Types:

    • Boot Sector: Infects MBR/boot sector.

    • File/Executable: Infects .exe, .com files.

    • Macro: Infects Office documents (Word, Excel).

    • Polymorphic/Metamorphic: Change code to evade detection.

• Worms: Self-replicating, network-propelled; no host file needed. Exploit vulnerabilities (e.g., buffer overflow) to spread automatically (e.g., WannaCry, SQL Slammer).

Specific Attack Types

• Ransomware:

  • Risks: Data encryption (loss/extortion), service disruption, financial loss, reputational damage, potential data leak if ransom unpaid.

  • Protection Mechanisms:

    1. Prevention: Regular patching, email filtering, user training, least privilege, application whitelisting.

    2. Mitigation: Frequent, offline backups (3-2-1 rule), network segmentation, EDR (Endpoint Detection & Response).

    3. Response: Isolate infected systems, identify variant, report to authorities, consider decryption tools (NoMoreRansom.org).

Mobile OS Vulnerabilities

• Vulnerable Components:

  • OS Kernel: Privilege escalation exploits.

  • System Apps/Services: Default apps (browser, messaging) with vulnerabilities.

  • Drivers/Firmware: Baseband (cellular), Wi-Fi, Bluetooth.

  • App Ecosystem: Malicious apps in third-party stores, permission abuses.

  • Hardware: Side-channel attacks (e.g., Spectre/Meltdown), NFC/RFID.

  • User Behavior: Jailbreaking/rooting, weak passcodes, public Wi-Fi.

• Android Security Levels:

  1. Linux Kernel: Mandatory Access Control (SELinux), user separation.

  2. System Services: Permission model (install-time/runtime), sandboxing (each app separate UID).

  3. Application Framework: Signed APKs, permission enforcement.

  4. Hardware: Trusted Execution Environment (TEE), Secure Boot, hardware-backed keystore.

VII. PLATFORM-SPECIFIC SECURITY (WINDOWS & HARDWARE)

Windows Internals & Security

• System Architecture (Neat Sketch Reference):

  • User Mode: Applications, subsystems (Win32, POSIX), DLLs.

  • Kernel Mode: NTOSKRNL.EXE (kernel), HAL (Hardware Abstraction Layer), Kernel Drivers.

  • Executive: Kernel services (Object Manager, Process Manager, I/O Manager, Security Reference Monitor).

  • Object Manager: Central namespace for kernel objects (processes, threads, files, events).

  Key: Everything is an Object with security descriptor.

• System Worker Threads: Kernel threads created by executive components to perform background work (e.g., lazy writer for cache flushing, memory manager work items). Run in kernel mode; not associated with user process.

• Windows Global Flags (GFlags): Debugging/diagnostic tool (in imagehlp.dll or gflags.exe). Controls system-wide or per-image behavior:

  • Show Loader Snaps: Debug DLL loading.

  • Enable Heap Tail Checking: Detect buffer overruns.

  • Increase Stack Trace Database: For memory leak detection.

• Winsock Architecture:

  • User-mode DLL: Ws2_32.dll provides API (socket(), bind(), etc.).

  • Kernel-mode Driver: AFD.SYS (Ancillary Function Driver) handles I/O completion, multiplexing.

  • Protocol Drivers: TCPIP.SYS (TCP/IP), etc.

  • Flow: App → Ws2_32 → AFD → Protocol Driver → NIC driver.

Hardware-Based Security

• Secure Coprocessor: Tamper-resistant hardware chip (e.g., TPM - Trusted Platform Module).

  • Role: Stores cryptographic keys, performs encryption/decryption/signing, measures boot process (measured boot), provides attestation (proves system integrity).

  • Functions: Key generation/storage, random number generation, platform authentication, sealed storage.

• Secure Wallet: Hardware/software component (e.g., TPM, Secure Enclave, TrustZone) that securely stores sensitive data (cryptographic keys, passwords, certificates).

  • Importance: Isolates secrets from OS (even compromised); prevents extraction via software attacks. Used for disk encryption (BitLocker), secure boot, DRM, payment systems.

VIII. NETWORKING & SOCKET PROGRAMMING

Sockets

• Concept: Software endpoint for bidirectional communication across network (or locally). Identified by socket address (IP + port for Internet; path for Unix domain).

• Types:

  | Type | Protocol | Connection | Reliability | Use Case | |------|----------|------------|-------------|----------| | Stream | TCP | Oriented | Reliable, ordered | Web (HTTP), SSH | | Datagram | UDP | Less | Unreliable, unordered | DNS, VoIP, streaming | | Raw | IP/ICMP | N/A | No transport layer | Network tools (traceroute) |

• Socket Programming Fundamentals (Client-Server):

  1. Server:

     • socket() → create socket.

     • bind() → assign address/port.

     • listen() → mark as passive, queue pending connections.

     • accept() → block until client connects; returns new socket for client.

     • read()/write() (or recv()/send()) → communicate.

     • close() → terminate connection.

  2. Client:

     • socket() → create socket.

     • connect() → actively connect to server address.

     • write()/read() → communicate.

     • close() → terminate.

  Key: Server uses bind/listen/accept; client uses connect.

Winsock (Windows Sockets)

• Functions & Uses:

  • WSAStartup(): Initialize Winsock library (must call first).

  • socket(): Create socket.

  • bind(), listen(), accept(), connect(): As above.

  • send(), recv(): Data transmission (flags parameter for control).

  • closesocket(): Close socket (not close()).

  • WSACleanup(): Uninitialize Winsock.

• Datagram Socket (UDP) Specifics:

  • Connectionless: No connect() needed for each send; use sendto() with destination address.

  • sendto(sock, buf, len, flags, dest_addr, addrlen): Send to specific address.

  • recvfrom(sock, buf, len, flags, src_addr, addrlen): Receive, get sender address.

  • Use Case: Broadcast/multicast, simple request-reply (DNS), where speed > reliability.

> [!TIP] EXAM STRATEGY

• 7-Mark Questions: Structure as: Definition → Components/Steps → Diagram (if asked) → Example/Application → Security Implications (where relevant).

• Prioritize ★★★★★ Topics: Buffer Cache, PCB, Semaphores, IPC, Sockets, Malware definitions are almost guaranteed.

• Diagrams: For Buffer Header/Pool, Process States, Windows Architecture, Socket Programming flow—practice neat sketches with labeled parts.

• Security Angle: For every OS concept (e.g., Buffer Cache, IPC, Sockets), briefly mention security relevance (e.g., buffer overflow in cache, secure IPC, socket firewall rules).

• Distinguish Closely: Binary vs. Counting Semaphore; Stream vs. Datagram Socket; DAC vs. MAC; Virus vs. Worm; Full Virtualization vs. Containerization.

\boxed{\text{Complete coverage of UNIT 4 per approved blueprint and past paper analysis.}}