Linux Internals — Capabilities, Namespaces, Seccomp, LSM and eBPF Security — DedSec Project

Purpose: Understand Linux isolation and privilege mechanisms deeply enough to review services, containers, Android/Termux constraints, and kernel-facing attack surface.

Learning objectives

• Explain Linux credentials, capabilities, namespaces, cgroups, seccomp, and LSM roles.
• Understand why root inside a container is not automatically host root, yet remains high risk.
• Recognize the kernel as a shared security boundary.
• Understand eBPF's security/observability role at a high level.
• Inspect your own process isolation without bypassing restrictions.

Linux credentials

Linux processes carry real/effective/saved user and group identifiers, supplementary groups, capability sets, namespaces, and security-module context. Files and IPC objects have ownership, mode bits, ACLs, labels, and other metadata.

Authorization is layered. A UID match may permit something that an SELinux policy denies, or a capability may permit an operation otherwise reserved for UID 0.

Capabilities

Linux capabilities divide traditional root authority into named units such as network administration, ownership override, raw I/O, or process-control abilities. A process can have permitted, effective, inheritable, bounding, and ambient capability sets depending on execution context.

Least privilege means removing capabilities not required by the workload. Some capabilities are so broad that they effectively undermine container boundaries when granted unnecessarily.

Namespaces

Namespaces provide separate views of selected kernel resources. Common namespace classes include:

• PID;
• mount;
• network;
• IPC;
• UTS/hostname;
• user;
• cgroup;
• time on supporting kernels.

Namespaces change view and identity context; they do not create a separate kernel. Containers combine namespaces with cgroups, capabilities, seccomp, LSM policy, filesystem layout, and runtime configuration.

User namespaces

User namespaces can map a process's namespace-local UIDs/GIDs to different host IDs. They support rootless containers and reduce host authority in some designs. Kernel attack surface reachable from unprivileged user namespaces must be carefully maintained, which is why distributions may differ in enablement policy.

Cgroups

Control groups account for and limit resources such as CPU, memory, process count, and I/O. They are important for availability containment. Namespaces answer “what can the process see?” while cgroups help answer “how much can it consume?”

Resource isolation is security-relevant because unlimited memory/process creation can become denial of service even when filesystem permissions are correct.

Seccomp

Seccomp filtering restricts which system calls a process may make. The Linux kernel documentation describes seccomp-BPF as a way to filter incoming system calls and reduce reachable kernel entry points.

A good seccomp profile is workload-specific. An overly broad profile offers little reduction; an overly narrow one breaks legitimate behavior. Generate policy from understanding, then test failure handling.

Landlock and unprivileged sandboxing

Landlock is a stackable Linux Security Module interface designed to let processes restrict their own ambient filesystem/network rights where supported. It illustrates an important pattern: applications can voluntarily reduce what compromised code would be able to reach.

Availability depends on kernel version/configuration; do not assume a specific Android/Termux device exposes it.

Linux Security Modules

LSM provides hooks for security modules such as SELinux and AppArmor. These systems can enforce mandatory policy beyond traditional discretionary permissions.

Android relies heavily on SELinux plus the application sandbox. Termux runs as an ordinary Android application UID and cannot simply acquire host root or bypass SELinux without the device itself being modified.

no_new_privs

The no_new_privs process attribute prevents execve() from granting additional privilege through mechanisms such as set-user-ID binaries. It is commonly combined with sandboxing/seccomp designs.

The principle is monotonic privilege reduction: after a process enters an untrusted parsing stage, it should be difficult to gain new authority.

Chroot versus isolation

chroot changes path resolution root for a process but is not a complete container/security sandbox by itself, especially for privileged processes. Modern isolation uses multiple controls rather than treating a changed filesystem root as sufficient.

Kernel attack surface

Every enabled syscall, filesystem, protocol, device driver, ioctl, eBPF interface, namespace operation, and kernel parser may contribute reachable code. Kernel self-protection aims to reduce exposed functionality and make exploitation harder through memory protections, read-only data, stack protections, CFI-like mechanisms, and restricted interfaces.

Keep kernels patched and minimize unnecessary privileged device access.

eBPF

eBPF executes verified programs in kernel-related contexts for networking, tracing, observability, and security. Because eBPF is powerful, kernel versions and configuration place restrictions on who can load programs and what helpers/types are available.

Defenders use eBPF for high-fidelity telemetry; platform maintainers also treat verifier/runtime bugs as serious kernel security issues. Do not attempt to bypass unprivileged eBPF restrictions.

/proc, /sys, and observability

Linux exposes process/system state through virtual filesystems. Containers and Android may mount filtered views. Read-only inspection can reveal namespace IDs, capability masks, cgroup membership, and mount layout.

For your own process, examples may include:

cat /proc/self/status
cat /proc/self/cgroup
cat /proc/self/mountinfo | head

Interpret what is available on your environment; permissions intentionally differ.

Safe isolation lab

On a disposable Linux VM with a container runtime, run a minimal container and compare inside/outside:

• PID view;
• hostname;
• network interfaces;
• mount table;
• UID mapping;
• capability set;
• cgroup membership.

Do not attempt to escape the container. Your goal is proving which boundaries exist and which kernel is shared.

Hardening review

For a service/container ask:

• can it run as non-root?
• which capabilities can be dropped?
• is the filesystem read-only where possible?
• are host devices/sockets mounted?
• is privileged mode disabled?
• are resource limits defined?
• is seccomp/LSM policy active?
• are secrets mounted narrowly?
• can it reach unnecessary networks?
• is the kernel maintained?

Guided study workflow

Before you begin

Complete Modules 24, 33, 53, 62, and 73 for comparison.

Practice task

Inventory namespaces, capabilities, cgroups, and security-module context for a process you own and a disposable container. Explain what each control isolates and what remains shared.

Evidence to keep

Sanitized /proc output, capability list, namespace diagram, and a least-privilege hardening plan.

Common mistakes to avoid

• assuming namespace root equals host root;
• treating containers as VMs;
• granting broad capabilities to fix permissions quickly;
• using chroot as a complete sandbox;
• trying to bypass Android/Linux security restrictions for a learning task.

Mastery check

Explain namespaces versus cgroups versus seccomp versus LSM, and identify which layer reduces kernel attack surface.

Continue with

Modules 75, 76, 80, 81, and 85.