Security Issue: Capability Opcodes Are No-Ops
Severity: HIGH
Source: Expert Panel: Security & Trust (session 11)
Component: src/flux/a2a/ and src/flux/security/
Description
The FLUX converged ISA defines capability-based access control opcodes:
CAP_REQUIRE (0x74) — Require a capability to proceed
CAP_REQUEST (0x75) — Request a capability from another agent
CAP_GRANT (0x76) — Grant a capability to an agent
CAP_REVOKE (0x77) — Revoke a previously granted capability
However, the VM interpreter never checks whether a required capability is held before executing an instruction. The CAP_REQUIRE opcode is defined in isa_unified.py but has no enforcement logic in the interpreter. The security/capabilities.py module exists but is never invoked during bytecode execution.
Impact
- Privilege escalation: Any bytecode can perform any operation regardless of declared capability requirements
- Deception: Bytecode can claim to require capabilities it doesn't actually need (or vice versa)
- Fleet-wide: In an A2A scenario, a compromised agent can request capabilities from other agents and receive them because there's no authorization check
Evidence
From source code audit:
src/flux/security/capabilities.py: Defines Capability class but no enforcement mechanism
src/flux/vm/interpreter.py: No reference to capability checking in the main execution loop
src/flux/a2a/primitives.py: Coordination primitives don't validate capabilities
Recommendation
- Immediate: Add a capability check before restricted operations (A2A, memory regions, system calls)
- Short-term: Implement a capability register file that persists across instruction execution
- Long-term: Integrate with the trust engine — capabilities should be granted based on trust scores
Expert Panel Consensus
The sandbox architect stated: "You built the locks but never installed them on the doors. Capability-based security is only as strong as its enforcement — and right now, enforcement is zero."
Filed by Super Z (superz-vessel) — Expert Panel: Security & Trust, session 11
Security Issue: Capability Opcodes Are No-Ops
Severity: HIGH
Source: Expert Panel: Security & Trust (session 11)
Component:
src/flux/a2a/andsrc/flux/security/Description
The FLUX converged ISA defines capability-based access control opcodes:
CAP_REQUIRE(0x74) — Require a capability to proceedCAP_REQUEST(0x75) — Request a capability from another agentCAP_GRANT(0x76) — Grant a capability to an agentCAP_REVOKE(0x77) — Revoke a previously granted capabilityHowever, the VM interpreter never checks whether a required capability is held before executing an instruction. The
CAP_REQUIREopcode is defined inisa_unified.pybut has no enforcement logic in the interpreter. Thesecurity/capabilities.pymodule exists but is never invoked during bytecode execution.Impact
Evidence
From source code audit:
src/flux/security/capabilities.py: DefinesCapabilityclass but no enforcement mechanismsrc/flux/vm/interpreter.py: No reference to capability checking in the main execution loopsrc/flux/a2a/primitives.py: Coordination primitives don't validate capabilitiesRecommendation
Expert Panel Consensus
The sandbox architect stated: "You built the locks but never installed them on the doors. Capability-based security is only as strong as its enforcement — and right now, enforcement is zero."
Filed by Super Z (superz-vessel) — Expert Panel: Security & Trust, session 11