Appearance
Runtime Blocks: Enforcement Reference
Telovix enforcement moves a sensor policy through three discrete states (observe, enforce-ready, enforced), each requiring an explicit operator action before the sensor begins killing or denying operations at the kernel level.
Prerequisites
operatorrole- Sensor already enrolled with assigned policy pack
- Sensor trust state:
healthy - Pack must have
enforcement_capable: true
Enforcement states for policy packs
Policy pack enforcement uses a three-state ladder. Each state change requires passing the verification checks and is recorded in the audit log.
| State | What it means |
|---|---|
observe | Pack is loaded. Events are collected and scored. No blocking or killing. Default for all new assignments. |
enforce_ready | Pack is loaded with enforcement intent. The sensor is in a verified state ready for enforcement. Does not yet block. Use as a final review gate. |
enforced | Full enforcement is active. The pack's enforcement rules are blocking or killing matching operations. |
Allowed transitions
| From | To | Allowed |
|---|---|---|
observe | enforce_ready | Yes, when all blocking conditions are clear |
enforce_ready | enforced | Yes, when all blocking conditions are clear |
| Any | observe | Always allowed (revert to observe from any state) |
observe | enforced | No (must pass through enforce_ready) |
enforced | enforce_ready | No (must go back to observe first) |
Returning to observe bypasses all prerequisites. There is no enforced ladder going downward: you go back to observe directly.
Prerequisites for advancing past observe
The following conditions must all be true before the Console permits a transition to enforce_ready or enforced:
| Prerequisite | Reason |
|---|---|
Pack is enforcement_capable: true | Only guard packs support enforcement (see Policy Packs) |
Sensor runtime_mode is live | Enforcement requires the full eBPF engine (tetragon_live_adapter) |
Sensor trust is not revoked or degraded | Degraded trust means the control path cannot be relied on |
Sensor health is not critical | A critical sensor cannot safely execute enforcement changes |
| Sensor is not disabled or revoked | A disabled or revoked sensor cannot be advanced |
Enforcement verification
Before advancing enforcement state, review the verification panel in the Console. Go to Sensors > [sensor] > Enforcement and check the readiness summary before using the state controls.
The verification panel shows:
| Field | Description |
|---|---|
current_enforcement_state | Current state on this sensor |
enforcement_capable | Whether the assigned pack supports enforcement |
runtime_mode | Engine adapter mode (live, compatibility, or simulated) |
sensor_health_state | Current health state |
trust_health | Current trust health |
recent_event_count | Number of relevant events in the last 24 hours |
observed_relevant_activity | Whether any events were seen in the observation window |
observation_window_hours | 24 (fixed observation window) |
evidence_entries | Up to 20 sample events from the last 24 hours |
distinct_event_kinds | Which event kinds fired in the observation window |
highest_severity_seen | The highest event severity observed |
readiness_class | NotReady, ReviewRequired, or CandidateForEnforceReady |
blocking_conditions | List of conditions preventing advancement |
caution_conditions | List of conditions requiring review before advancing |
recommended_next_step | Text guidance based on the readiness class |
Readiness classes
| Class | Meaning |
|---|---|
NotReady | One or more blocking conditions exist. Resolve before attempting to advance. |
ReviewRequired | No hard blockers, but caution conditions require operator review before advancing. |
CandidateForEnforceReady | All conditions are clear. Safe to advance to enforce_ready. |
Blocking conditions (any one blocks advancement):
- Pack is not enforcement-capable
- Sensor is not in live runtime mode
- Sensor trust is revoked or degraded
- Sensor health is critical
- Pack is already at maximum enforcement state
- Sensor is disabled or revoked
Caution conditions (require review, do not block):
- Trust health is not fully healthy
- Sensor health is degraded or watch
- No recent activity observed for this pack (may indicate the pack has not been running long enough)
- Pack is already at
enforce_ready(review event history before advancing toenforced)
Setting enforcement state
Requires operator role. In the Console, go to Sensors > [sensor] > Enforcement and use the state controls to advance or revert the enforcement state.
- Advance from
observetoenforce_ready: use the Advance button after confirming the readiness class isCandidateForEnforceReady. - Advance to
enforced: use the Advance button again after reviewing event history inenforce_readystate. - Revert to
observefrom any state: use the Revert button - no prerequisites apply.
Each state change is recorded in the audit log with action type sensor_enforcement_state_changed, including the from-state, to-state, and the operator who made the change.
Action types in TracingPolicy
Three action types are available in TracingPolicy YAML:
Post (observe)
yaml
matchActions:
- action: PostRecords the event and continues. The operation is not blocked or interrupted. The process continues running. Use this for all initial rule deployment.
Signal with argSig: 9 (kill)
yaml
matchActions:
- action: Signal
argSig: 9Sends SIGKILL to the matching process after the hook fires. The process has already begun executing at the hook point. Signal terminates it after the fact. Use when pre-execution denial is not available (kprobe hooks).
Override with argError: -1 (block)
yaml
matchActions:
- action: Override
argError: -1Returns an error to the kernel before the operation completes. The process cannot proceed with the operation. Use on BPF LSM hooks (lsmhooks) where pre-execution denial is possible. argError: -1 returns EPERM.
Override is not valid on kprobe hooks. It only works on BPF LSM-backed hooks. Using Override on a kprobe will not compile or will silently have no effect.
Built-in enforcement templates
These templates are available from Policies > Enforcement > New Rule in the Console:
| Template ID | Hook mechanism | Default action |
|---|---|---|
block-kmod-load | BPF LSM kernel_read_file | Override (blocks module load before it enters the kernel) |
block-user-namespace | BPF LSM userns_create | Override (blocks CLONE_NEWUSER) |
block-raw-sockets | BPF LSM | Override |
block-capset-sysadmin | BPF LSM | Override |
kill-ptrace-attach | BPF LSM ptrace_access_check | Signal (kills attaching process) |
block-execve-tmp | BPF LSM bprm_check_security | Override (blocks execution from /tmp, /dev, /run/user, /proc/self/fd) |
block-memfd-create | BPF LSM | Override |
block-pivot-root | BPF LSM | Override |
block-mount-syscall | BPF LSM | Override |
block-unshare | BPF LSM | Override |
block-bpf-load | BPF LSM | Override |
block-socket-raw | BPF LSM | Override |
block-chmod-suid | BPF LSM | Override |
custom | Operator-supplied YAML | Defined by the YAML |
Templates that use Override require BPF LSM to be enabled on the sensor host kernel. Verify with cat /sys/kernel/security/lsm | grep bpf. See Requirements.
Impact preview
Before creating any enforcement rule, use the impact preview panel in the Console to see how many events in the last 7 days would have matched. In the Console, go to Policies > Enforcement > New Rule, select a template, and the impact preview loads automatically. It returns total_events, has_data, top_binaries, and event_kinds. A count of 0 may mean the pattern never fires on this sensor, or it may mean the coverage event kinds are not in the recent history.
Rollback and recovery
Reverting enforcement state: always allowed by going to Sensors > [sensor] > Enforcement and using the Revert button to return to observe.
Disabling an enforcement rule: go to Policies > Enforcement, select the rule, and use the Disable toggle. The rule is removed from the sensor's next heartbeat response and the sensor stops applying it within one heartbeat cycle (up to 15 seconds).
Sensor restart after override failure: if Override rules block a critical system call unexpectedly, the sensor service can be stopped, the compiled policy removed from disk, and the service restarted to clear enforcement policies before they are reapplied from the next heartbeat.