Kernel Security Primitives, Attack Surface and Runtime Trust — DedSec Project

Kernel Security Primitives, Attack Surface and Runtime Trust The kernel is the mediator for memory, processes, files, devices, networking, and privilege. This module deepens the earlier OS…

The kernel is the mediator for memory, processes, files, devices, networking, and privilege. This module deepens the earlier OS lessons by teaching how to map kernel attack surface and hardening primitives without turning kernel exploitation into an operational recipe.

Learning objectives

By the end of this module you should be able to:

Explain System-call boundary and connect it to a concrete trust boundary or security invariant.
Explain Drivers and device interfaces and connect it to a concrete trust boundary or security invariant.
Explain Kernel memory safety and connect it to a concrete trust boundary or security invariant.
Explain Privilege model and connect it to a concrete trust boundary or security invariant.
Explain Module and boot trust and connect it to a concrete trust boundary or security invariant.
Explain Race conditions and connect it to a concrete trust boundary or security invariant.

Deep concepts

1. System-call boundary

System calls expose kernel services to user processes. The reachable syscall set depends on architecture, kernel configuration, namespaces, seccomp, capabilities, and the process execution model.

2. Drivers and device interfaces

Device drivers, filesystems, network protocols, ioctls, USB, Bluetooth, graphics, and virtual devices add complex parsers and state machines inside privileged code. Reducing unused functionality reduces risk.

3. Kernel memory safety

Kernel bugs include out-of-bounds access, use-after-free, races, integer issues, and reference-lifetime mistakes. Modern kernels deploy hardening such as KASLR, stack protections, hardened allocators, CFI-related defenses, and memory-safety improvements, but none replaces correct code.

4. Privilege model

UIDs, capabilities, namespaces, LSMs, keyrings, credentials, and file permissions interact. “root inside a namespace” is not automatically equivalent to unrestricted host privilege.

5. Module and boot trust

Secure Boot, module signing, measured boot, lockdown modes, and update provenance constrain which privileged code is accepted. Operational key management determines whether those features remain meaningful.

6. Race conditions

Kernel concurrency means an object can change between validation and use. Security analysis must consider locking, reference counting, RCU-style lifetimes, interrupt contexts, and multi-core scheduling.

7. Attack-surface reduction

Disable unused filesystems/protocols/modules, minimize device access, constrain containers, keep kernels updated, and select hardened configurations appropriate to the workload rather than relying on one mitigation.

8. Telemetry

Audit, LSM logs, eBPF-based observability, kernel warnings, crash reports, module events, and integrity measurements can reveal abnormal kernel-adjacent activity. Capture enough context to distinguish faults from malicious behavior.

Authorized exercises

Exercise 1 — Inventory the enabled kernel-facing interfaces in an owned Linux VM: devices, filesystems, modules, namespaces, and exposed sockets; classify them by necessity

Inventory the enabled kernel-facing interfaces in an owned Linux VM: devices, filesystems, modules, namespaces, and exposed sockets; classify them by necessity.

Exercise 2 — Compare process capabilities before and after applying a least-privilege service configuration in a disposable lab

Compare process capabilities before and after applying a least-privilege service configuration in a disposable lab.

Exercise 3 — Read a harmless kernel crash report or public bug description and identify object lifetime, privilege context, and mitigation layers without reproducing exploitation

Read a harmless kernel crash report or public bug description and identify object lifetime, privilege context, and mitigation layers without reproducing exploitation.

Knowledge checks

Explain the most important trust boundary in Kernel Security Primitives, Attack Surface and Runtime Trust without naming a security tool.
Give one example where cryptographic or authentication success still does not imply authorization success.
Describe one stale-state or replay condition relevant to this module.
Identify one telemetry source that can support a strong conclusion and one blind spot it still leaves.
Explain how you would turn a discovered weakness into a regression test rather than a one-time finding.