Introduction

Churchill is a runtime-integrity product for Linux hosts running security-critical applications. It protects a running application from being tampered with while it executes, and it does something most security tools will not: when it verifies that a workload has been compromised, it terminates the affected process immediately rather than writing an alert and waiting for someone to respond.

The problem Churchill solves

On-disk scanning and network monitoring miss a whole class of attacks that happen entirely inside a live process. An attacker who has gained some foothold on a host can manipulate a workload that is already running, and never touch a file that a scanner would notice. The threats Churchill is built to stop include:

Runtime tampering. Code or data inside a running process is altered after it has started, so the program no longer does what its trusted binary on disk says it does.
Memory injection. Malicious code is written directly into a process’s memory and executed from there, bypassing any on-disk inspection.
Unauthorized privilege escalation. A protected application is quietly granted capabilities or privileges it was never meant to hold, opening the door to broader host or container compromise.
Library hijacking. A trusted binary is subverted at runtime by forcing it to load attacker-controlled libraries in place of the ones it shipped with.

These attacks share a common shape: the binary on disk still looks fine, but the process in memory has been changed. That gap is the runtime blind spot Churchill is designed to close.

A fail-closed approach

Most endpoint tooling follows an observe-and-alert model. It notices something suspicious, raises an alarm, and leaves a window of time between detection and response during which the compromised process keeps running and a human has to decide what to do.

Churchill is fail-closed, and its response is graduated. Actions that are merely unauthorized (an unapproved program trying to execute, a debugger trying to attach) are refused. The workload sees an ordinary permission error, the refusal is recorded as evidence, and the application keeps running. A denial costs you nothing.

Verified compromise of the workload itself is different. When Churchill confirms that a running process is no longer what it is supposed to be, it terminates it. Detection is sub-second. The kill sequence freezes the entire process tree before delivering the kill, so nothing can fork, escape, or race the decision. The host then goes into lockdown. The terminated application stays down, across service restarts and host reboots, until an operator has investigated and cleared it. There is no observe-only mode for fatal events.

On kernels that support the optional kernel enforcement layer (built on BPF LSM), a whole class of these detections becomes synchronous denials: the kernel refuses the action before it happens. On kernels without it, the same classes are still detected, bounded by Churchill’s monitoring cadence rather than blocked in-line. That difference is logged explicitly, never silently. The kill-on-compromise contract is the same either way.

Who it is for

Churchill is built for operators responsible for high-assurance Linux workloads where a single undetected process modification would be unacceptable: financial and transaction systems, sensitive data processing, and other mission-critical services. It runs on modern Linux distributions on x86_64, IBM LinuxONE (s390x), aarch64, and ppc64le (little-endian).

What an operator gets

As an operator, you work with Churchill through a web dashboard rather than by logging into individual hosts. From there you:

Enroll hosts and register the applications you want protected.
Watch the health of your fleet in real time through continuous heartbeats.
Review tamper-evident evidence of what each host has reported.
Investigate lockdowns when a host has terminated a compromised process.
Replay sealed recordings of terminal sessions, with every replay itself recorded on the audit chain.
Run planned changes through a Change Advisory Board, so a legitimate update is approved instead of killed.
Review your own account and see who has operator access.

The result is a single place to deploy, observe, and govern runtime protection across your whole fleet, backed by an enforcement model that stops a compromise instead of just describing it.

To see how the pieces fit together, continue to How Churchill works. To get a host protected as quickly as possible, jump to the Quick start.