Teaching / Cybersecurity / OS Security Labs

OS Security Labs

Chroot Jail · Biba Integrity Model · Virtualization Architecture

Three self-contained interactive labs covering core OS security concepts. Each lab lets you manipulate the key variables of a security model and immediately observe the consequence — no server, no installation.

Isolation Lab 1 — Chroot Jail

A chroot jail remaps the root of the filesystem for a specific process. From inside the jail, the process believes / literally is the jail directory — it cannot see, traverse, or open anything above it.

Scenario: a web server (nginx, running as www-data) has been exploited. The attacker has arbitrary file-read. Toggle between free and jailed to see what they can reach — then try the access tests.

Filesystem — attacker's view
// (system root)
├─bin/system binaries
├─etc/
├─passwduser accounts
└─shadowpassword hashes!
├─home/
└─alice/
└─.ssh/id_rsaSSH private key!
├─proc/1/memprocess memory
├─var/lib/mysql/database files
JAIL ROOT: /srv/www
├─index.html
├─config.phpdb credentials
├─uploads/
└─.htaccess
Access attempts — click to test
/etc/shadow Password hashes for all system users
click
/home/alice/.ssh/id_rsa Alice's SSH private key
click
/proc/1/mem Memory of PID 1 (init)
click
/var/lib/mysql/ Raw database files
click
/srv/www/config.php Web app DB credentials (inside jail)
click
../../../etc/shadow Path traversal attempt (../..)
click
Integrity Lab 2 — Biba Integrity Model

The Biba model protects data integrity — preventing low-trust processes from corrupting high-trust data. Its two rules are elegantly symmetric and directly implemented in Windows as Mandatory Integrity Control (MIC).

No Write Up
A subject cannot write to an object at a higher integrity level. Low-trust processes cannot contaminate high-trust data.
No Read Down
A subject cannot read from an object at a lower integrity level. High-trust processes should not be influenced by untrustworthy input.
Quick scenarios — click to load Browser → write → System32 Email attachment → write → /tmp System daemon → read → /tmp Text editor → read → user doc Browser → read → download Kernel → write → kernel module
Subject (process)
Web Browser Low
e.g. Chrome renderer sandbox
Email Attachment Viewer Low
Untrusted external content
Text Editor Medium
Standard user application
System Daemon High
Elevated OS service
OS Kernel System
Highest trust, full privilege
Operation
|
Object (resource)
/tmp/ download Low
Untrusted, world-writable temp dir
~/Documents/report.docx Medium
Standard user data
/etc/sudoers High
System configuration — privilege rules
C:\Windows\System32 High
Windows system directory (MIC: High)
/sys/module/kernel System
Kernel modules — system-level trust
Select a subject, operation, and object above
Architecture Lab 3 — Virtualization Architecture & Compromise Simulator

Select an architecture to see how the software stack is arranged. Then click any component in the diagram to simulate a compromise — and see what else falls with it. This is the core question when evaluating isolation guarantees.

Architecture Stack — click a layer to compromise it
Security Analysis
Click a layer in the stack diagram to see what an attacker who controls that component can reach.
Architecture Comparison
Property Type 1 Type 2 Container
Hypervisor runs on Hardware directly Host OS N/A (container runtime)
Guest OS Full, isolated Full, isolated None — shares host kernel
Kernel isolation Strong Strong (but extra layer) None — kernel shared
If hypervisor/runtime compromised All VMs at risk All VMs at risk All containers at risk
If Host OS compromised Only bare hypervisor at risk Hypervisor + all VMs Runtime + all containers
Performance overhead Low Medium Very low
Typical use VMware vSphere, Hyper-V, KVM VirtualBox, VMware Workstation Docker, Kubernetes