CSY102 Week 11 Beginner

Practice virtualization and container basics before moving to reading resources.

Computing Systems & OS

Track your progress through this week's content

Opening Framing: "Separate Them" Is the Oldest Security Strategy

We have spent this unit studying boundaries: memory boundaries (Week 5), identity boundaries (Week 3), service boundaries (Week 6), network boundaries (Week 8), and evidence boundaries (Week 9).

Virtualisation and containers represent the same idea at a higher level: when you cannot fully trust a system, you place it inside a controlled box.

Modern computing survives by dividing reality into compartments. Cloud providers run thousands of customers on the same physical hardware. Enterprises run untrusted workloads alongside critical systems. Developers test dangerous code without risking their machines.

But boxes are only secure if their walls are real. This week is about what the walls are made of — and how they crack.

Virtualisation is enforced separation at the hardware boundary. Containers are enforced separation at the operating-system boundary. Both exist because isolation is survival.

Mental Model: Apartments vs Hotel Rooms

Think of two forms of separation:

  • Virtual Machines (apartments): each tenant has their own plumbing, wiring, locked front door, and separate utility meters. The building structure separates units.
  • Containers (hotel rooms): each guest has a private room with a lock, but they share plumbing, electrical, HVAC, and building management. Walls are thinner.

Both can be safe. But the failure modes differ:

  • Apartments: breaches require breaking structural walls or compromising building management. Higher isolation, higher overhead.
  • Hotels: breaches can exploit shared infrastructure — a problem with the plumbing affects everyone. Lower isolation, lower overhead.

The security question is not "Are VMs/containers secure?" The question is: What exactly is isolated from what, and what still leaks?

Mental model: VMs are apartments with separate infrastructure. Containers are hotel rooms with shared infrastructure. Choose based on your threat model and trust requirements.

1) What Is a Virtual Machine?

A virtual machine is a full operating system running inside an emulated (or hardware-assisted) environment. To the guest OS, it looks like real hardware — real CPU, real memory, real disk. The guest doesn't know (and shouldn't need to know) that it's virtualized.

The controlling layer is the hypervisor (also called Virtual Machine Monitor or VMM). The hypervisor:

  • Allocates resources: CPU time, memory regions, storage, network interfaces
  • Enforces boundaries: prevents VMs from accessing each other's memory or resources
  • Mediates hardware access: translates guest requests to physical hardware
  • Manages lifecycle: starts, stops, snapshots, migrates VMs

There are two types of hypervisors:

  • Type 1 (bare-metal): runs directly on hardware — VMware ESXi, Microsoft Hyper-V, Xen. Used in data centers and cloud providers.
  • Type 2 (hosted): runs on top of a host OS — VirtualBox, VMware Workstation. Used for development and testing.

Security implication: the hypervisor becomes a high-trust authority. If the hypervisor is compromised, every VM it manages becomes negotiable. The hypervisor is to VMs what the kernel is to processes — the ultimate arbiter of access.

Key insight: VMs provide strong isolation because each has its own kernel. But they all trust the hypervisor, making it a critical security boundary.

2) What Is a Container?

A container is not a full OS. It is a process (or group of processes) running with isolation features that make it appear to have its own environment:

  • Filesystem namespace: sees its own root filesystem, isolated from host
  • Process namespace: sees only its own processes, PID 1 is the container's init
  • Network namespace: has its own network interfaces, IP addresses, routing tables
  • User namespace: can map container root to unprivileged host user
  • Resource limits (cgroups): constrained CPU, memory, I/O usage

But containers share the same underlying kernel with the host and with each other. This is the defining security trade-off: containers are lightweight and fast, but kernel sharing means shared fate.

A kernel vulnerability affects all containers on that host. A container escape — where a process breaks out of its namespace — grants access to the host and potentially all other containers. The isolation is enforced by kernel features, not hardware boundaries.

Container runtimes like Docker, containerd, and podman manage the creation and lifecycle of containers. Orchestrators like Kubernetes manage containers at scale across many hosts.

Key insight: containers isolate at the OS level using namespaces and cgroups. They're lighter than VMs but share more — including the kernel attack surface.

3) Isolation Guarantees: What You Can Rely On

In well-configured systems, isolation aims to guarantee:

  • Process separation: one workload cannot directly see, signal, or control another workload's processes
  • Filesystem separation: one workload cannot read or write another's data unless explicitly shared
  • Network separation: communication paths are explicit and controlled; workloads can't sniff each other's traffic by default
  • Resource governance: CPU, memory, disk I/O, and network bandwidth can be constrained to prevent resource exhaustion attacks
  • Privilege separation: workloads can run with minimal privileges, reducing impact if compromised

The security strategy is to make compromise local — not systemic. If one container or VM is breached, the isolation should prevent lateral movement to others.

This is called blast radius reduction. You assume breaches will happen and design systems so that each breach affects as little as possible.

However, these guarantees depend entirely on correct configuration. Default settings may not provide the isolation you expect. Security requires deliberate design.

Key insight: isolation is about limiting blast radius. Assume breach, contain damage.

4) Where Isolation Fails: How Boundaries Crack

Isolation fails when boundaries are misconfigured, bypassed, or undermined:

  • Escapes: a workload exploits a vulnerability to break out of its VM/container boundary and access the host or other workloads
  • Over-privilege: a workload is granted unnecessary capabilities — running as root, privileged mode, host namespace access
  • Shared secrets: credentials, API keys, and tokens are reused across environments, so compromising one compromises all
  • Shared storage: a mounted volume becomes a data bridge between workloads that should be isolated
  • Control plane compromise: Kubernetes API, Docker socket, or hypervisor management interface becomes the attacker's lever
  • Side channels: timing attacks, cache attacks, or resource exhaustion can leak information across isolation boundaries

The most dangerous attacks target the control layer: hypervisors, container runtimes, orchestration systems, and management APIs. Compromise the orchestrator, and you compromise everything it orchestrates.

Common misconfigurations that break container isolation:

  • Running containers with --privileged flag
  • Mounting the Docker socket (/var/run/docker.sock) into containers
  • Running as root inside containers without user namespace remapping
  • Disabling seccomp or AppArmor profiles

Key insight: isolation is only as strong as its weakest configuration. Defaults may not be secure; hardening is essential.

Real-World Context: Isolation Failures in Practice

Isolation failures are not theoretical. They happen in production:

CVE-2019-5736 (runc container escape): A vulnerability in runc, the underlying container runtime used by Docker and Kubernetes, allowed a malicious container to overwrite the host runc binary. When an administrator ran any docker/kubectl command, the compromised binary executed with host privileges. One container escape led to full host compromise.

CVE-2020-2732 (KVM hypervisor vulnerability): A flaw in the Linux KVM hypervisor allowed a guest VM to cause a denial-of-service against the host, potentially affecting all VMs on that host. Even the hardware-level isolation of VMs depends on correct hypervisor implementation.

Kubernetes misconfigurations: Security researchers regularly find Kubernetes clusters exposed to the internet with default credentials, privileged containers, or the Kubernetes API accessible without authentication. Tesla, Weight Watchers, and others have been breached through misconfigured Kubernetes.

Virtualisation and containers intersect with everything we've studied: orchestration runtimes are services (Week 6), automated deployments are scheduled (Week 7), containerised services expose network surfaces (Week 8), logs must escape compromised containers (Week 9), and container images are supply chain objects (Week 10).

The modern compromise is not "hack one server." It is "move through the layers that manage many servers."

Common thread: isolation is engineering, not magic. Every layer depends on correct implementation and configuration. The control plane is often the weakest link.

Guided Lab: Comparing Isolation Boundaries

This lab focuses on understanding the difference between VM and container isolation by examining what is actually separated and what is shared.

Lab Objective

Compare isolation mechanisms in VMs and containers, identify shared resources, and understand the security implications of each model.

Environment

Step 1: Examine Container Isolation (if Docker available)

# Run a container and examine its view
docker run -it --rm alpine sh

# Inside container:
ps aux                    # What processes do you see?
cat /etc/os-release       # What OS does it think it is?
hostname                  # What is the hostname?
id                        # What user are you?

# Exit and compare to host
exit
ps aux | wc -l            # How many processes on host?

Observe: the container sees a limited view. But what kernel is it running?

Step 2: Examine Shared Resources

# From host, while a container runs:
docker run -d --name test alpine sleep 3600

# See container process from host perspective
ps aux | grep sleep       # Container process visible on host!
cat /proc/$(pgrep -f "sleep 3600")/cgroup  # See cgroup assignment

# Check kernel sharing
docker exec test uname -r  # Container kernel version
uname -r                   # Host kernel version (same!)

Observe: containers share the host kernel. A kernel vulnerability affects all containers.

Step 3: Compare to VM Isolation (conceptual or practical)

If you have a VM available:

The hypervisor isolates at a lower level than container namespaces.

Reflection (mandatory)

  1. What is the fundamental difference between how VMs and containers achieve isolation?
  2. Why does kernel sharing in containers create "shared fate"?
  3. When would you choose VMs over containers for security reasons?

Lab: Isolation Models — Virtual Machines vs Containers

Goal: observe how modern systems create isolation and reason about what is truly separated versus what is shared.

Choose ONE path (observation only). Both are valid.

Virtual Machine Observation

  1. Identify your VM environment (VirtualBox, VMware, Hyper-V, cloud VM like EC2/GCE).
  2. List what appears "dedicated" to the VM:
    • Its own operating system and kernel
    • Its own users and authentication
    • Its own filesystem and storage
    • Its own network interfaces and IP addresses
  3. List what must be shared with the host:
    • Physical CPU cycles (time-sliced by hypervisor)
    • Physical memory (partitioned by hypervisor)
    • Physical storage hardware (virtualized by hypervisor)
    • Physical network hardware (virtualized by hypervisor)
  4. If possible, check VM-specific details: 
    # Inside VM - detect virtualization
systemd-detect-virt        # Linux
dmesg | grep -i virtual    # Look for hypervisor messages
  5. Concept question: Why is the hypervisor considered a high-trust component? What can the hypervisor do to any VM it manages?

Container Observation (Practical if Docker available, Conceptual otherwise)

  1. Understand that containers are processes with isolation features, not separate VMs: 
    # If Docker is available:
docker run -d --name demo nginx
ps aux | grep nginx        # Container process visible on host!
docker top demo            # View processes inside container
  2. List what containers have their "own view" of (namespaces):
    • Filesystem (mount namespace) — own root filesystem
    • Processes (PID namespace) — sees only its own processes
    • Network (network namespace) — own interfaces and IPs
    • Users (user namespace) — can remap UID/GID
    • Hostname (UTS namespace) — own hostname
  3. List what containers definitely share:
    • The host kernel — same kernel version, same vulnerabilities
    • Kernel resources — same syscall interface
    • Hardware — through the shared kernel
  4. Concept question: Why does kernel sharing change the security model? What happens if a kernel vulnerability is discovered?

Deliverable (submit):

Checkpoint Questions

  1. Explain the difference between hardware-level isolation (VMs) and OS-level isolation (containers). What does each share?
  2. Why does compromising a hypervisor have system-wide consequences? What can an attacker do from this position?
  3. Why are containers faster and lighter than virtual machines? What trade-off enables this?
  4. What kinds of misconfiguration can turn container isolation into an illusion? Give two specific examples.
  5. How does Week 11's concept of "blast radius reduction" connect to Week 5's memory isolation and Week 6's service boundaries?

Week 11 Outcome Check

By the end of this week, you should be able to explain:

Next week: Hardening, baselining, and system assurance (Capstone) — how to reduce attack surface systematically, make systems predictable, and build environments that are resistant by default.

🎯 Hands-On Labs (Free & Essential)

Practice virtualization and container basics before moving to reading resources.

🎮 TryHackMe: Intro to Docker

What you'll do: Run basic containers, inspect images, and understand isolation boundaries.
Why it matters: Containers share kernels — understanding that boundary is core to their risk model.
Time estimate: 1.5-2 hours

Start TryHackMe Intro to Docker →

📝 Lab Exercise: VM vs Container Comparison

Task: List three security differences between VMs and containers and map each to a real risk.
Deliverable: Comparison table with isolation boundary + risk example.
Why it matters: Isolation type determines what "escape" actually means.
Time estimate: 45-60 minutes

🏁 PicoCTF Practice: General Skills (Virtualization Basics)

What you'll do: Complete beginner challenges that reinforce environment separation and tooling.
Why it matters: Practical comfort with isolated environments is essential for safe testing.
Time estimate: 1-2 hours

Start PicoCTF General Skills →

💡 Lab Tip: Containers are fast to deploy, but VM isolation is stronger. Choose based on threat model.

🛡️ Secure Configuration & Virtualization Hardening

Virtualization adds isolation, but only if the host and hypervisor are hardened. Containers share the kernel, so configuration choices are critical. 

Container hardening checklist:
- Run as non-root users
- Use minimal base images
- Enable seccomp and AppArmor/SELinux
- Drop unnecessary capabilities
- Read-only filesystems where possible

Hypervisor hardening: Keep host OS patched, restrict management interfaces, and separate admin networks from guest traffic.

📚 Building on CSY101 Week-13: Threat model escape paths across isolation layers. CSY201: Advanced hardening applies these controls in production virtualization stacks.

Resources

Mark the required resources as complete to unlock the Week completion button.

Verified Resources & Videos

Isolation is about reducing blast radius — not eliminating risk. The closer you are to the kernel or hypervisor, the more dangerous compromise becomes. VMs and containers are tools, not solutions; security depends on how they're configured.

Weekly Reflection

Reflection Prompt (200-300 words):

Consider an organization that runs a web application with the following components: a public-facing web server, an application backend, and a database containing customer data.

The organization is deciding between two architectures:

Analyze the security trade-offs:

Make a recommendation and justify it based on security principles from this week. What additional controls would you recommend regardless of which option is chosen?

A strong response will compare isolation mechanisms specifically, identify the critical trust boundaries in each architecture, and recommend compensating controls that address the weaknesses of the chosen approach.

← Previous: Week 10 Next: Week 12 →

Week 11 Quiz

Test your understanding of the weekly concepts.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Take Quiz