SELinux type enforcement
Every process and every object has a security context: user:role:type:level. The type is what TE policy operates on. Policy rules:
allow httpd_t httpd_sys_content_t:file { read getattr open };
type_transition httpd_t var_log_t:file httpd_log_t;First rule: a process in type httpd_t may read files of type httpd_sys_content_t. Second: when httpd_t creates a file in a var_log_t directory, the new file gets type httpd_log_t automatically.
The policy compiles to a binary loaded by the kernel. audit2allow processes denied entries from /var/log/audit/audit.log into proposed allow rules during policy development. The full reference policy is ~100K rules; distributions ship pre-built policies for common services.
gVisor
Google's user-space kernel (2017). A gVisor sandbox intercepts every syscall from the guest process and re-implements it in Go user-space, calling the host kernel only for a small, vetted subset.
Trade-offs:
- Much smaller host-kernel attack surface than running containers directly on shared kernel.
- Performance cost: syscalls take 2-10x longer; I/O-heavy workloads are particularly impacted.
- Compatibility cost: some syscalls and features are unimplemented or partially implemented.
Used by Google for serverless functions, Cloud Run, and isolation of untrusted workloads in Borg.
Firecracker
AWS's minimal hypervisor (2018), built on KVM. Boots a microVM in ~125 ms with ~5 MB memory footprint. Used to run Lambda functions and Fargate tasks: each customer's code gets its own VM.
Trade-offs vs gVisor:
- Stronger isolation (full VM boundary vs user-space kernel).
- Lower performance overhead per call than gVisor; higher startup cost than a container.
- Simpler attack surface than a general-purpose hypervisor.
SGX, SEV-SNP, TDX
Three approaches to hardware-rooted isolation, with different security and use-case profiles:
- Intel SGX (2015): per-process enclaves up to ~256 MiB. The host OS is treated as untrusted; only the enclave code runs in confidentiality. Long history of side-channel attacks (Foreshadow, LVI, SGAxe); deprecated for client CPUs in 2021 but still used in server settings via SGX2 (DCAP).
- AMD SEV-SNP (2020+): per-VM encryption with integrity. The hypervisor is untrusted; the VM's memory is encrypted with a key only the CPU knows. Attestation lets the VM prove its measurements to a remote verifier.
- Intel TDX (2022+): similar to SEV-SNP. Per-VM "trust domain" with hardware-isolated memory. Designed as the SGX successor for confidential VMs.
All three suffer from variations of side-channel attacks (cache, branch predictor, speculative execution). Confidential computing reduces the trusted base but does not eliminate trust in the hardware vendor.
Where confidential computing fits
Realistic uses:
- Multi-party computation where two parties want to jointly compute over their combined data without revealing it to each other (Signal's private contact discovery used SGX for years).
- Cloud customers who want hardware proof that the cloud provider cannot read their memory.
- DRM and platform attestation for licensed content.
Where it does not help:
- Software bugs inside the enclave. SGX does not protect against your buggy code; it protects against the OS reading your memory.
- Side channels that the hardware does not promise to defeat (most do not).
- Compromise of the trusted hardware vendor's signing keys (rare but consequential).
The practical layering
A modern hardened container deployment combines:
- Linux capabilities dropped to the minimum.
- seccomp-bpf with a deny-by-default profile.
- SELinux or AppArmor for MAC.
- Read-only root filesystem, non-root UID inside the container.
- Container runtime sandbox (gVisor or Kata Containers) for untrusted workloads.
- Optionally a confidential VM (SEV-SNP, TDX) for the host.
Each layer adds work for an attacker. Together they raise the bar substantially above "shared kernel, default config."