Blog

Two Linux programs running under the same user account do not normally share private memory. Each process has its own virtual address space, and the kernel controls access when processes request resources. That protection depends on the kernel being trustworthy—and on the authority granted to each process.

Why the kernel is a security boundary

The kernel manages memory, processes, files, devices, and networking. Applications run in user space and request kernel services through system calls, such as opening a file or creating a socket. The kernel allows an operation only when its rules permit it. A bug in an application might expose that application's data; a kernel bug can potentially cross boundaries between applications or affect the whole system.

For many security decisions, the kernel needs to know who is making a request and which resource they want to use. File ownership and permissions matter, but so do process isolation, privilege checks, system-call restrictions, and controls on code that runs inside the kernel.

Identity, privileges, and capabilities

Linux tracks each process's credentials, including user and group IDs. A process generally inherits them from its parent, though approved mechanisms can change them. The kernel uses those credentials to check permissions, so a service running as an ordinary user should have less reach than one running as root.

Root is not the only way to grant elevated authority. Linux capabilities divide many traditionally root-only operations into narrower privileges. A service that needs to bind to a low-numbered network port, for example, may need CAP_NET_BIND_SERVICE rather than broad root access. Capabilities still need care: some are powerful enough to undermine isolation, and granting one to a program that handles untrusted input raises the stakes of a bug.

Dropping privileges after startup helps only if the process has no other route back to the same authority. For a packaged service, inspect its service configuration; a displayed non-root user does not tell the whole story.

Isolation mechanisms are not interchangeable

Linux has several controls that limit different kinds of access or resource use. Combining them can reduce the damage if an application behaves unexpectedly:

• Namespaces give processes separate views of resources such as process IDs, mount points, and network interfaces. They change what a process can see, but a namespace alone is not a complete security boundary.
• Control groups (cgroups) account for and limit resource use, including memory and CPU time. They can keep a workload from exhausting a host, but they do not decide which files it may read.
• Seccomp filters which system calls a process may make. A well-designed filter reduces the kernel interfaces available to a process; it does not guarantee that every allowed call uses safe arguments.
• Linux Security Modules (LSMs) provide hooks for additional access-control policies. SELinux and AppArmor are familiar examples. Their rules can restrict a service beyond ordinary user and group permissions.

Containers often combine several of these features. They also share the host kernel, so a container is not automatically equivalent to a virtual machine with its own kernel. Isolation depends on the container's configuration, its assigned privileges, and the security of that shared kernel.

What mandatory access control adds

Ordinary file permissions let an owner decide who can access a file. A mandatory access control policy can also restrict a process even when its user ID would otherwise permit the action. A web service, for example, might be allowed to read its content directory but denied access to unrelated home directories. The result depends on the installed policy and whether it is enforcing; the presence of SELinux or AppArmor alone does not prove that a particular operation is blocked.

Kernel code and the cost of extra interfaces

Loadable kernel modules run with kernel-level authority. They support hardware and system features, but an untrusted or vulnerable module can do far more harm than a normal user-space program. Limit who can load modules, install only needed components, and get updates through trusted channels.

Some systems use Secure Boot and signed kernel modules to help control what code loads during boot and into the kernel. The guarantees depend on firmware settings, signing keys, distribution configuration, and whether the controls are enforced. A signature speaks to a module's provenance, not whether it is free of bugs.

Linux also has mitigations against classes of memory and control-flow attacks. Availability varies with the kernel version, build options, and processor support. These measures make exploitation harder, but known vulnerabilities still need timely fixes.

Updates, configuration, and verification

Kernel security also takes maintenance. Distributions often backport fixes without adopting the newest upstream version number, so a version string alone is a poor test of patch status. Check your distribution's security notices and package information for the kernel you actually run. After installing an update, find out whether a reboot is needed: the files on disk may be current while the running kernel is still the old one.

On a Linux machine you administer, start with read-only checks:

1. Run uname -r to identify the running kernel release. Compare it with installed kernel packages and your distribution's notices.
2. Use lsmod to list loaded modules. An unfamiliar name calls for investigation; it is not proof of compromise.
3. Check SELinux or AppArmor with the status tool provided by your distribution, as applicable. Confirm whether a policy is active and enforcing.
4. Review security-relevant service settings, especially the service user, granted capabilities, and sandboxing options. Test configuration changes in a lab or during a maintenance window.

As you review a service, distinguish available from active. The kernel may support seccomp or an LSM while that service has no restrictive policy. Start with its launch configuration and the status of its security controls, then test its expected functions after a change. If a new policy prevents the service from starting, diagnose the denial before changing the rule; do not disable the host's protections just to get it running.