leodido

Didn't leave it out. It was grouped with AppArmor in the table, which was imprecise. I'm splitting the row. SELinux labels are on the inode, so renames preserve the context. Copy resistance is policy-dependent (works for `sandbox_t`, not for `unconfined_t`). See my reply to `botanicalfriend` user above.

Ah, and thank you for pointing to `fapolicyd`! It's the closest prior art to what we're doing at the exec layer, and its `ld.so` bypass prevention via policy rules addresses the exact dynamic linker evasion I wrote about.

Two architectural differences worth noting, which I guess you are already aware of. First, `fapolicyd` is a userspace daemon... The kernel blocks until the daemon responds. This works, but the daemon itself becomes a single point of failure, isn't it? If it stalls or is killed, the system either deadlocks or fails open (hence the deadman's switch). Veto keeps hash computation and enforcement inside the BPF LSM hook. The BPF program can't (hopefully lol) crash and requires no context switch for the decision.

Second, `fapolicyd` defaults to an allowlist model: anything requesting execution must be in the trust database. That's a stronger default posture than our current denylist. We're starting with denylist because it's the lower-friction entry point for teams adopting agent security incrementally: you block known things without having to enumerate all good things first. In 2 words: different tradeoffs.

Fair point on SELinux: grouping it with AppArmor was imprecise. Thank you for spotting it. As you mentioned, SELinux labels are on the inode, so a rename does preserve the security context. I'll split the row in the table.

On the copy attack: the `sandbox_t` -> `tmp_t` type transition you describe is a real defense, but it's policy-dependent. It's my understanding that `sandbox_t` is one of the most locked-down SELinux domains, while most interactive users (AI agents included) run as `unconfined_t`, where `tmp_t` files are executable, and the copy attack succeeds. So, whether a copied binary gets an executable type (or not) actually depends on the transition rules in the loaded policy.

Instead, content-addressable enforcement doesn't depend on policy configuration. The hash follows the content regardless of where it lands or what label it gets.

User `walterbell` is right. Padding changes the hash, so the modified binary wouldn't match the denylist. It also wouldn't match anything the system has seen before since it's now an unknown binary... The veto denylist approach is for catching known-bad binaries by identity. If you need to block unknown/modified binaries, you flip the model: allowlist known-good hashes and deny everything else. It's a different threat model, so it requires a different mode.

Author here. I helped creating Falco (CNCF runtime security) and built this (Veto) to fix the path-based identity problem we all shipped a decade ago. The dynamic linker bypass in the "where it breaks" section is the part I'm most interested in discussing. It's a class of evasion that no current eval framework measures. Happy to answer questions about the BPF LSM implementation.

Hello, glad your test run went well!

Would you mind telling us more at [email protected] regarding the pinning? Not sure I got what you mean, just want to be sure. Feel free to send us the details at that email.

Thank you, ~leo

AFAIK not.

Written with Ragel targeting Golang.

Provides partial parsing, too.

2μs to parse an average syslog line.

Feedbacks always welcome.