5.2 Linux Deep Isolation: MAC, seccomp, and Host Hardening
In Discretionary Access Control, the resource owner can modify permissions; once a process acquires that account, it often gains read access to all data associated with that account. Mandatory Access Control, seccomp, and namespaces introduce independent constraints from different perspectives. However, no single mechanism can transform untrusted code into absolute security.
SELinux and AppArmor Limit Object Access
SELinux typically enforces policies based on labels assigned to processes and objects:
atlas_api_t process
can read atlas_config_t
can write atlas_data_t
cannot read shadow_tAppArmor uses profile configuration files bound to executable paths, along with network and capability permissions, adopting a path-oriented model. The choice between SELinux and AppArmor often depends on the distribution ecosystem, tooling availability, and team expertise, rather than a simple comparison of "which is more secure."
Policies should be derived from actual application data flows. Simply setting SELinux to permissive mode or applying an AppArmor unconfined rule to a process is merely disabling enforcement; blindly generating allow rules in response to denials turns attack patterns into legitimate access patterns.
A sound approach involves first collecting minimal normal behavior in a test environment, crafting narrow policies, and conducting both positive and negative testing before deploying to production enforcement. Production denials must be correlated with version and request context for investigation, never treated as false positives.
Narrowing the syscall Attack Surface with seccomp
seccomp-BPF executes actions such as allow, errno, kill, or trap based on syscall numbers and limited parameter data. It cannot understand semantic paths like "only allow opening /srv/data," because the memory pointed to by a pointer may change during execution. File path constraints should instead be enforced jointly by DAC/MAC, namespaces, and secure APIs.
A default deny policy with a carefully curated allowlist provides stronger boundaries and is more resilient to compatibility issues, yet it remains vulnerable to breaking changes in libc, language runtimes, JIT compilers, or behavior across new versions. Profiles must be generated and tested on the target architecture, kernel version, and actual workloads, including edge cases and upgrade scenarios.
Returning EPERM can allow applications to fail gracefully, but it may also conceal attack detection; directly killing the process is more explicit, though it could be exploited by malicious requests for denial-of-service. The choice of action must be balanced against service recovery and monitoring capabilities.
Namespace Changes the View, Not the Kernel
Mount, PID, network, IPC, UTS, and user namespace mechanisms isolate the resources that processes perceive. Containers combine these isolation techniques with cgroup, capability, and LSM (Linux Security Modules) controls.
Containers running on the same host still share the same kernel. Vulnerabilities in the kernel, overly permissive capabilities, exposed host sockets, privileged containers, and unsafe device mappings can all lead to breaches. High-risk, untrusted tenants should use lightweight VMs, microVMs, or isolated nodes to achieve stronger kernel boundaries.
Particularly avoid mounting the container runtime socket into regular applications, this typically grants equivalent management privileges over the host container. Mounts involving hostPID, hostNetwork, mounting the host root filesystem, and running in privileged mode all require separate, explicit exception approvals.
Cgroup and rlimit Resource Availability Fault Tolerance
Isolation must also control resource consumption. Attackers could exhaust process counts, memory, CPU, file descriptors, or disk space. cgroup limits resource shares and caps, while rlimit constrains per-process or per-user boundaries, both must work in tandem:
- Request-level limits on body size, decompression, and execution time;
- Separate disk partitions and log rate constraints;
- OOM (Out-of-Memory) policies and service restart backoff;
- Global capacity reservations to prevent all sandboxes from reaching their limits simultaneously.
Setting limits too low turns legitimate peak usage into self-denied service. These thresholds must be determined through stress and degradation testing.
The Kernel and Boot Chain Determine Underlying Trustworthiness
The host baseline includes:
- Using supported kernels and distributions, and tracking security patches and required reboots;
- Minimal installation, disabling unused daemons, protocols, and kernel modules;
- Enforcing Secure Boot or verified boot based on device threat modeling to validate boot components;
- Restricting access to module loading, BPF, perf, debugfs, ptrace, and kernel logging;
- Auditing changes to critical configurations, accounts, services, and packages;
- Time synchronization, remote log forwarding, and integrity protection to prevent attackers from erasing local evidence.
Live patching can reduce some reboot windows, but it does not eliminate the need for restarts in all kernel or user-space updates. The asset inventory must clearly distinguish between "installed version" and "currently running version."
Sandbox Must Verify Escape to the Next Layer
A defense composition can be represented as:
Low-privilege UID
+ Minimal capability
+ Read-only or minimal file view
+ MAC policy
+ seccomp syscall allowlist
+ cgroup/rlimit
+ Isolated network and temporary identity
+ Updates, detection, and recoveryTesting must verify normal functionality and actively attempt to read host secrets, access metadata, create raw sockets, ptrace neighboring processes, mount filesystems, launch a fork bomb, fill the disk, and invoke disallowed syscalls. Controls should block these actions and produce actionable telemetry.
The next chapter shifts the focus to host-to-host: how segmentation, identity-aware access, outbound control, and network detection collectively restrict lateral movement.
References
- Linux Kernel, Threat Model
- Linux Kernel, Seccomp BPF
- SELinux Project, SELinux Notebook
- AppArmor, Documentation