An operating system (OS) is the software layer between your applications and the physical hardware. It manages CPU time, memory, disk, and network — and it enforces every security boundary your system relies on. If the OS is compromised, every application running on top of it is compromised too.

​
What an OS Actually Does

The OS solves two core problems that would otherwise make multi-user, multi-process computing impossible: Abstraction — Raw hardware (disk controllers, network cards, memory buses) is complex and inconsistent across manufacturers. The OS wraps these in clean, stable APIs called system calls. When your code calls fopen(), it triggers a system call that the OS handles regardless of which brand of SSD you have. Arbitration — CPU cycles, RAM, and I/O bandwidth are finite. The OS multiplexes them:
  • Time multiplexing: scheduling different processes on the CPU in turn
  • Space multiplexing: dividing RAM and disk among processes and users
  • Isolation: ensuring a crash in Process A does not corrupt Process B’s memory
The kernel is the core of the OS — the component that runs in privileged mode with direct hardware access. Everything else (your shell, applications, utilities) runs in restricted user space and must ask the kernel for resources through system calls.

​
Unix, Unix-Like, and POSIX

Unix was developed at AT&T Bell Labs in 1971 and shaped modern computing. Its philosophy — everything is a file — means hardware devices, network sockets, and data streams are all accessed through the same file-descriptor interface. This simplicity makes Unix-like systems predictable and auditable. Unix-like operating systems follow the same design principles without being direct Unix descendants. Linux, macOS, and BSD are all Unix-like. Most servers, cloud infrastructure, and security tooling run on Unix-like systems, so understanding them is foundational to cybersecurity work. POSIX (Portable Operating System Interface — the X stands for Unix) is an IEEE standard that defines a common API contract. If an OS is POSIX-compliant, programs written to the standard will compile and run on it without modification. Practically, this means:
OSPOSIX status
macOSCertified compliant
LinuxDe-facto compliant (rarely pays for certification)
WindowsNot compliant — uses Win32 API; requires WSL for POSIX tooling
POSIX standardizes file I/O calls (open(), read(), write()), process control (fork(), exec()), threading (pthreads), and the behavior of CLI tools like ls, grep, and awk. This is why shell scripts written on Linux typically run unchanged on macOS.

​
Ports and Attack Surface

A network port is a logical endpoint number (0–65535) that directs incoming traffic to a specific service. Port 22 is SSH, port 443 is HTTPS, port 3306 is MySQL. The OS kernel manages which process is listening on each port. From a security perspective, every open port is a potential entry point. A port is only open when a process is actively listening on it. A fully locked-down machine has all ports closed — no services listening, so there is nothing for an attacker to connect to.
Port numbers 0–1023 are well-known ports reserved for common services and require root/administrator privileges to bind. Ports 1024–49151 are registered ports. Ports 49152–65535 are ephemeral (used for outbound connections).
You can list open ports and the processes bound to them with: 
# Linux
ss -tulnp

# macOS
sudo lsof -iTCP -sTCP:LISTEN -P
Firewall rules typically filter traffic by port number, blocking connections to services that should not be reachable from the network.

​
Virtualization

Virtualization is the technology that makes one physical machine behave like many separate computers. The OS abstracts CPU, RAM, disk, and network into software-defined resources that can be sliced up and assigned to isolated virtual environments. A single powerful server can run one Linux VM, one Windows VM, and a dozen containers simultaneously — each believes it has its own dedicated hardware. This is the foundation of modern cloud infrastructure. The component that makes this possible is the hypervisor (also called a Virtual Machine Monitor). It sits between the physical hardware and the virtual machines, controlling how much CPU, RAM, disk, and network each VM receives and enforcing isolation between them.

Virtual Machine (VM)

Runs on: A hypervisor layer above physical hardwareHas: Its own full OS, virtual CPU, virtual RAM, virtual disk, virtual NICIsolation: Strong — each VM has a separate kernelUse case: Running different operating systems on the same hardware, strong isolation between tenants, security research sandboxesExamples: Kali Linux in VirtualBox, cloud instances on AWS EC2

Bare-Metal Machine

Runs on: Physical hardware directlyHas: Full access to real CPU, RAM, disk, NIC — no virtualization overheadIsolation: Process-level only (enforced by the OS kernel)Use case: Maximum performance, latency-sensitive workloads, situations where hypervisor overhead is unacceptableExamples: Dedicated database servers, high-frequency trading systems

​
The VM Security Model

VMs provide a hard isolation boundary that bare-metal processes do not. When you run malware inside a VM for analysis, it cannot (under normal circumstances) reach the host OS or other VMs on the same machine. This makes VMs a staple of:
  • Security research — analyzing malware in a contained environment
  • Penetration testing — running attack tools that shouldn’t touch production systems
  • Multi-tenancy — hosting multiple customers on shared infrastructure without cross-contamination
The security guarantee of a VM rests entirely on the hypervisor. If the hypervisor has a vulnerability, the isolation can be broken — an attack called VM escape. This is covered in depth in Kernel & User Space. Virtualization also introduces risks from shared physical resources. Two VMs on the same host share CPU caches, memory buses, and sometimes storage controllers. An attacker who controls one VM can potentially infer what the other VM is doing by measuring timing differences — a side-channel attack.

​
Mitigating Virtualization Risks

The source materials identify three key mitigations for virtualization security:
  1. Patch management — Keep hypervisors and guest OSes updated. Hypervisor vulnerabilities are critical because they undermine the isolation of every VM on the host.
  2. Principle of least privilege — Give VMs and users only the minimum permissions they need. A web-server VM should not have access to management interfaces.
  3. Disable unused ports — Every service listening on a network port is a potential entry point. Shut down anything you are not actively using.