Design safe enforcement of command-argument restrictions

[JimBugwadia]

User outcome

Operators can distinguish approved and prohibited invocations of the same executable, with an explicit prevention guarantee.

Current behavior

Executable enforcement matches resolved paths. exectrace captures bounded argv after exec for reporting; #228 has no userspace verdict rendezvous.

Scope

• Evaluate pre-execution hooks and argument availability for BPF-LSM and fmod_ret separately.
• Define bounds, truncation/unreadable handling, execve/execveat, interpreters, scripts and argument-mutation risks.
• Prototype one concrete allow/deny invocation and decide whether the operation can be prevented safely.
• Produce an implementation issue only after the design names a supported hook and stable inputs.

Acceptance

• Design and evidence distinguish preventing exec from blocking a later operation or killing a process.
• The prototype checks an allowed invocation, denied invocation and mutation/alternate-exec cases.
• Unsupported combinations fail explicitly; no promise that arbitrary shell syntax has one semantic interpretation.

Dependencies and boundaries

Needs design; informed by #171. Does not block CIDRs or path prefixes. Arbitrary userspace CEL and post-event kill are not equivalent to inline prevention.

Validation and completion

• Table-driven tests pin the stated invariant, including invalid input and policy updates.
• For code changes: make build and make test; significant changes also require make kind-install and a targeted behavioral check. Pipeline, collector, evaluator, or reporter changes require make smoke-quickstart.
• Kernel changes use the pinned BPF builder, generated-artifact verification, verifier loading, and allowed/denied behavior tests on supported hook paths.
• Update DESIGN, development guidance where affected, and the RuntimePolicy reference and limits. Every rejected user rule must reach an operator log and policy condition; count every observation drop. Preserve the reporter redaction boundary.