leodido · HackerTrans

4 maanden geledendiscuss

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.

leodido

4 maanden geledendiscuss

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.

leodido

4 maanden geledendiscuss

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.

leodido

4 maanden geledendiscuss

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.

leodido

4 maanden geledendiscuss

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.

comments