Security model

This document exists to prevent ambiguity, misuse and incorrect assumptions by users, auditors and contributors.

For the thinking behind the architecture, see the design philosophy; for the details of putting it into practice, see the development guide.

Threat model

Wrong Boot is designed for systems where the operator has control of the machine before an incident occurs and wants a pre-configured response to remain available even when normal user-space mechanisms may no longer be reliable.

The model assumes:

• The operator can load and configure the kernel module before the relevant incident,
• The kernel is trusted at the time the module is loaded,
• The configured action is intentionally chosen by the operator,
• Trigger inputs such as keyboard events, USB events and network traffic may originate from untrusted sources,
• User-space processes may become unavailable, compromised or too late to respond,
• The system may become physically or logically hostile after activation.

The module assumes a trusted kernel at load time and explicit operator intent behind every parameter it is given. It does not try to detect or defend against a kernel that is already compromised when insmod runs.

Trust boundaries

Privileges

Loading the module requires the privileges necessary to load a kernel module on the target system, typically including CAP_SYS_MODULE where module loading is permitted.

This requirement is intentional.

Wrong Boot is not a privilege-escalation mechanism. It assumes the operator already has sufficient control of the system to install and configure kernel code.

Once loaded, the module executes in kernel context and its configured user-space action is invoked through the kernel's User Mode Helper mechanism.

The resulting action therefore runs with the privileges available to that execution path, rather than with the restricted privileges of an ordinary unprivileged application.

The configured action should consequently be treated as a high-privilege operation.

Kernel/user-space execution boundary

Trigger detection occurs at the kernel boundary. When a trigger condition is satisfied, the core decides whether execution should proceed and defers the configured action out of the trigger context.

The action is then handed back to user space through the kernel's User Mode Helper mechanism.

This creates an intentional asymmetry:

• Detection and activation are handled by the kernel.
• The configured consequence is executed in user space.

The configured action therefore inherits the privileges and execution environment of the User Mode Helper path and should be treated as a high-privilege operation.

One-shot execution guarantee

All triggers converge on a single execution latch. At most one activation can consume it even when multiple triggers activate concurrently.

The result is an at-most-once execution guarantee, not a guarantee that every trigger condition will be observed.

The activation latch and deferred execution mechanics are described in development philosophy.

Module unload and payload lifetime

The configured action is not detached from the module's lifecycle.

Because the execution work uses UMH_WAIT_PROC, the work item remains active while the spawned user-space command is running.

During module removal, the core flushes the execution work:

flush_work(&exec_work);

Therefore, removing the module while its configured action is still executing can block until that action terminates.

This is an operational consequence of the execution model rather than a recovery mechanism.

Operators should test payload termination behavior before relying on module removal as part of an incident-response procedure.

Interception position

Wrong Boot observes trigger events through kernel mechanisms rather than relying on a persistent user-space process to report them.

This means stopping or modifying the user-space application that would normally consume an event does not necessarily prevent the kernel trigger from observing it.

The exact visibility and ordering of an event depend on the subsystem and hook used by the trigger. A kernel-level attacker remains outside the protection model.

Configuration exposure

Module parameters are not secret storage.

Configuration supplied to the module may be exposed through kernel mechanisms such as:

/sys/module/wrong8007/parameters/

Depending on the parameter and system configuration, values may therefore be observable by privileged or otherwise permitted local processes.

The same principle applies to logging.

Trigger and execution diagnostics may expose operational information through the kernel logging system.

Consequently:

A trigger phrase, network matching value, USB rule or configured command should not be treated as confidential merely because it was supplied to the kernel module.

Operators should avoid treating module parameters as a secure secret-management mechanism.

Payload security

The project deliberately does not prescribe what the configured action should do.

A payload may record information, notify another system, isolate the machine, start recovery, modify system state, destroy information, or perform another operator-defined action.

The module therefore cannot guarantee that a payload is safe.

The payload inherits the privileges and execution context of the User Mode Helper path and may have consequences far beyond the trigger itself.

Any artifacts or side effects beyond the module's own trigger handling are the responsibility of the configured payload, not of Wrong Boot.

Consequently:

A malicious, accidental or poorly tested command can cause significant system impact.

Guarantees and limitations

Wrong Boot provides architectural guarantees, but its behavior still depends on the kernel, the surrounding system and the configured payload.

Architectural guarantees

The design provides:

• Centralized activation arbitration
• At-most-once execution
• Separation between trigger detection and execution
• Fail-closed initialization
• Deferred execution from trigger contexts

Environment-dependent behavior

The following remain dependent on the surrounding system:

• Successful trigger observation
• Availability of the required kernel subsystems
• Successful module loading
• User-space process creation
• Availability of /bin/sh and other execution components
• Completion of the configured payload

Outside the model

Wrong Boot does not protect against:

• A compromised or untrusted kernel
• Failure to load the module before an incident
• Incorrect trigger or payload configuration
• Runtime failure of the underlying trigger subsystem
• Failure or unintended behavior of the configured payload
• Physical loss, destruction, or power-off of the machine (unless configured)
• Confidentiality loss of module parameters or diagnostic information

Any general system-security failures outside the module's scope.

Non-goals

• Install itself automatically, or persist across reboots on its own.
• Obfuscate its own code or behavior, or hide its presence from lsmod/dmesg.
• Escalate privileges. It requires root to load and runs its configured command as root, but does not elevate anything beyond that.
• Communicate externally, unless the operator's own EXEC payload does so.
• Accept commands from any source other than the module parameters supplied at load time. There is no runtime control channel, remote or local.
• Modify kernel memory outside its own module state.
• An adversary with a kernel exploit or arbitrary kernel read/write. At that point they own the switch too.
• Chip-off forensic access to storage performed on media that is never booted with Wrong Boot active again.
• Cold-boot attacks already in progress against DRAM-resident encryption keys. Cutting power lets DRAM remanence decay, but the decay window is hardware-dependent and outside this project's control.
• Hardware implants (keyloggers, firmware-level “evil maid” tampering) introduced before any trigger fires.
• An adversary who removes both AC and battery power simultaneously, before detection and execution can complete. Wrong Boot is fast; it is not instantaneous.