D3-KBPI Kernel-based Process Isolation: Namespaces, seccomp and Protected Processes Verified

A compromised process is only as dangerous as what the kernel lets it see and call, so isolating processes at the kernel decides whether one foothold becomes a host compromise. MITRE D3FEND names this countermeasure Kernel-based Process Isolation (D3-KBPI) and defines it as "Using kernel-level capabilities to isolate processes." It sits under the Isolate tactic as a child of Execution Isolation (D3-EI), whose techniques "prevent application processes from accessing non-essential system resources, such as memory, devices, or files." D3FEND's entry is brief: a one-line definition, an example comment ("e.g. KVM") and a single reference on the seccomp sandbox. This card fills in the practical side: which kernel features deliver the isolation on Linux, Windows and BSD, which ATT&CK techniques D3FEND relates to it, and how to verify that a process really runs isolated. It is written for platform, container and endpoint engineers.

Key takeaways

• It is a family of kernel features, not one product. Linux namespaces, cgroups and seccomp, Windows protected processes and AppContainer, FreeBSD jails and kernel hypervisors such as KVM all isolate processes using the kernel.
• Each feature isolates something different. Namespaces limit what a process sees, seccomp limits which system calls it can make, protected processes stop other processes reading its memory. Strong isolation layers several.
• The kernel documentation is blunt about limits. The Linux seccomp documentation states "System call filtering isn't a sandbox": it reduces kernel attack surface and must be combined with other measures.
• D3FEND's ATT&CK links are inferred. They come from the Process artefact and cluster on credential dumping from LSASS, SAM and LSA secrets, server components such as web shells, and tampering with security tools.
• Verify from inside the process. Check the namespace links, the seccomp mode and the protection level of the running process; configuration files only show intent.

D3-KBPI at a glance

How it works

The kernel is the only component that sees every process, so it can enforce boundaries that the process cannot undo from user space. Kernel-based isolation works along four axes, and real deployments combine them.

Linux: namespaces and seccomp

Namespaces give a process its own view of a global resource. The namespaces(7) manual page lists eight types, and notes that since Linux 3.8 no privilege is required to create a user namespace, which is why unprivileged container runtimes work and also why user namespaces enlarge the kernel surface reachable by unprivileged users. Each process exposes its namespaces as links under /proc/[pid]/ns/; two processes share a namespace when the links have the same inode.

seccomp lets a process install a BPF filter over its own system calls. Per the kernel documentation, the task must set no_new_privs (or hold CAP_SYS_ADMIN in its namespace) first, filters are inherited across fork and execve when those calls are allowed, and when several filters apply the most restrictive action wins. Return actions range from SECCOMP_RET_KILL_PROCESS through SECCOMP_RET_ERRNO and SECCOMP_RET_USER_NOTIF to SECCOMP_RET_LOG and SECCOMP_RET_ALLOW. The kernel documentation also warns filter authors to check the architecture value because system call numbers differ between calling conventions. Deeper coverage is in the seccomp Guide and the Linux Namespaces and cgroups Security Guide.

Windows: protected processes and AppContainer

LSA protection runs LSASS as a protected process. Microsoft documents that nonprotected processes then cannot read its memory or inject code, protected LSASS cannot be debugged, and any plug-in or driver it loads must be Microsoft-signed. It is enabled with the RunAsPPL REG_DWORD under HKLM\SYSTEM\CurrentControlSet\Control\Lsa (1 with UEFI lock, 2 without UEFI lock), the Group Policy setting "Configures LSASS to run as a protected process", or the Intune setting LocalSecurityAuthority/ConfigureLsaProtectedProcess. On Windows 11 22H2 and later it is turned on automatically for new, enterprise-joined installations on devices that support HVCI.

AppContainer isolates an application across six areas Microsoft lists: credential, device, file, network, process and window isolation. Resources are blocked by default and granted explicitly, and the contained app's kernel objects are sandboxed from other processes.

BSD and hypervisors

FreeBSD jails extend the chroot model by virtualising access to the file system, the set of users and the networking subsystem; VNET jails add a separate network stack. D3FEND's own example is KVM, the Linux kernel's hypervisor, where each guest runs as a process isolated by the kernel and hardware virtualisation together. Hardware-enforced isolation as a separate technique is covered in D3-HBPI Hardware-based Process Isolation.

ATT&CK techniques D3FEND relates to D3-KBPI

Relationship type: inferred only. D3FEND derives these through the shared Process artefact (D3-KBPI isolates Process) and labels them inferred, experimental and subject to change (D3FEND knowledge graph 1.6.0, checked November 2026). D3FEND still lists the pre-v20 Disable or Modify Tools sub-technique of Impair Defenses, which ATT&CK v20 revoked; its v20 successor T1685 is shown below. Each ID was checked against ATT&CK v20.

D3FEND's page also names parent techniques without IDs (for example OS Credential Dumping and Server Software Component). For detection detail see T1003 OS Credential Dumping, T1505 Server Software Component Defensive Guide and T1685 Disable or Modify Tools Defensive Guide. NHI Mgmt Group view, not part of D3FEND: container breakout, T1611 Escape to Host, is the attack that most directly tests this boundary.

Where identity fits

LSASS, the SAM and LSA secrets hold machine and service account credentials as well as user ones, so the credential dumping rows are as much about non-human identities as human ones. In containers, the isolation boundary also decides whether a compromised workload can read another workload's mounted service account token or secret. Process isolation is a strong reason to give each workload its own identity rather than share one. See Credential Guard and VBS for the virtualisation-based protection that complements LSA protection.

Implementation steps

1. Classify workloads. Separate internet-facing services, credential-holding processes (LSASS, secret agents, identity services) and multi-tenant workloads; these get isolation first.
2. Windows: audit LSA protection, then enforce. Set AuditLevel = 8 under the LSASS.exe Image File Execution Options key, reboot and review CodeIntegrity Operational events 3065 and 3066 for plug-ins that would fail. Fix or replace them, then set RunAsPPL. Use the value without UEFI lock (2) during pilot so rollback is a registry change; the UEFI-locked value (1) needs Microsoft's opt-out tool to remove.
3. Containers: set a baseline. Run containers without host PID, IPC or network namespaces, without privileged mode, with all capabilities dropped and a RuntimeDefault seccomp profile. Kubernetes Pod Security Standards encode these in the Baseline and Restricted levels; apply them in audit or warn mode first, then enforce per namespace.
4. Linux services: use the init system. Service managers can apply namespaces, capability bounding and system call filters per unit. Start with logging actions (SECCOMP_RET_LOG) to learn which calls a service needs, then switch to a deny action.
5. Consider user namespaces. Rootless containers reduce the damage of breakout, but unprivileged user namespace creation also widens kernel attack surface for every local user. Decide per host role.
6. Roll back safely. Keep isolation settings in configuration management with the previous version tagged, and roll out by ring: test hosts, one production pool, then the fleet.

How to verify it works

• Windows LSA protection: confirm System log WinInit event 12, "LSASS.exe was started as a protected process with level: 4", after each boot. Missing events across the fleet are the gap list.
• Linux seccomp: read the Seccomp: line in /proc/[pid]/status for the running process (2 means filter mode); a 0 means no filter is applied whatever the configuration says.
• Linux namespaces: compare /proc/[pid]/ns/ link inodes of the workload with those of PID 1 on the host; identical pid or net links mean the workload shares the host namespace.
• Container policy: query the cluster for pods with hostPID, hostNetwork, hostIPC, privileged or Unconfined seccomp, and alert on admission of any new one.
• Adversary emulation: in an authorised exercise, attempt an LSASS memory read from an administrator session on a protected host and a host namespace query from inside a test container; both should fail and be logged.

Limits, bypasses and failure patterns

• Kernel bugs: every process shares the kernel, so a kernel privilege escalation crosses namespace and seccomp boundaries. Patch kernels promptly and keep the reachable system call set small.
• Privileged containers: privileged mode, host namespaces and broad capabilities such as CAP_SYS_ADMIN undo most of the isolation; they are the usual root cause of container escape.
• Kernel-mode attackers: protected processes stop user-mode access; a malicious or vulnerable signed driver runs in the kernel and is outside that boundary. Pair with driver blocklists and HVCI.
• Allow lists that drift: a seccomp profile copied once and never revisited either blocks a new release or, more often, is replaced with Unconfined to "fix" it.
• Isolation without least privilege: an isolated process with a mounted host directory or a powerful service account token still reaches what that mount or token allows.
• Offline credential theft: LSA protection protects LSASS memory, not copies of registry hives or the NTDS database taken with backup privileges.

Framework mapping

Related countermeasures

• Application-based Process Isolation (D3-ABPI): isolation built into the application, such as browser sandboxes. See D3-ABPI Application-based Process Isolation.
• Hardware-based Process Isolation (D3-HBPI): isolation enforced by processor features.
• System Call Filtering (D3-SCF): mandatory access control over system calls, which D3FEND places under Access Mediation. See D3-SCF System Call Filtering.
• Executable Allowlisting (D3-EAL): controls what may run, where KBPI controls what a running process may reach. See D3-EAL Executable Allowlisting.

Practitioner checklist

• Run LSA protection on every supported Windows host, piloted in audit mode first.
• Monitor WinInit event 12 fleet-wide and treat its absence as a finding.
• Apply a seccomp profile to every production container; never run Unconfined without a recorded exception.
• Block host PID, IPC and network namespaces and privileged mode by admission policy.
• Drop all Linux capabilities and add back only what a workload proves it needs.
• Decide per host role whether unprivileged user namespaces stay enabled.
• Check isolation from the running process (/proc status and ns links), not only from configuration.
• Keep kernels patched; isolation depends on the kernel being sound.
• Give each isolated workload its own service identity and secrets.

Standards and references

• MITRE D3FEND: Kernel-based Process Isolation (D3-KBPI)
• Linux kernel documentation: Seccomp BPF (SECure COMPuting with filters)
• Linux man-pages: namespaces(7)
• Microsoft Learn: Configure added LSA protection
• Microsoft Learn: AppContainer isolation
• FreeBSD Handbook: Jails and Containers
• Kubernetes: Pod Security Standards
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-39 Process Isolation)

Related NHI Mgmt Group resources: seccomp Guide · Linux Namespaces and cgroups Security Guide · Container Runtime Security Guide · M1048 Application Isolation and Sandboxing · MITRE D3FEND Guide