3 ms·

Hi westurner, I just spent some time going through the Amla and agentvm threads you linked, fascinating stuff. I see you've been tracking this intersection spec

Hi westurner, I just spent some time going through the Amla and agentvm threads you linked, fascinating stuff. I see you've been tracking this intersection specifically around resource isolation. This is the core of our Phase 3 roadmap. To answer where CSL fits in that stack: We distinguish between Layer 7 (Business Logic) and Layer 3/4 (Resource Isolation). Re: WASM Integration You're right to separate them. Our mental model for the future (Q2) looks like this: 1. Wasmtime/Host (Layer 4) -> Handles "Can I access socket?" (Capabilities) 2. CSL Engine (Layer 7) -> Handles "Should I transfer $10k?" (Policy) Ideally, CSL acts as a Host Function Guard—basically intercepting tool calls before they hit actual syscalls. We're currently looking at two paths: OPTION A: Host-Side Enforcement The host intercepts tool calls. CSL (compiled to WASM) runs in the host context to verify the payload before execution. Pros: Guest can't bypass. Cons: Policy updates need host restart. OPTION B: Component Model Using `wit` interfaces where the agent imports a policy-guard capability. Pros: It's part of the contract. Cons: More complex to compose. Starting with A, migrating to B as Component Model matures makes sense to us. Re: SELinux/seccomp vs CSL The example from your Amla work actually illustrates this perfectly. Even with a perfect sandbox, an agent can call `transfer_funds(dest="attacker")` if it has the capability. seccomp can't reason about "attacker" vs "legitimate_user"—it just sees a valid syscall. - seccomp stops the agent from hacking the kernel - CSL stops the agent from making bad business decisions You need both layers for actual safety. Re: eWASM / Costed Opcodes This is something we're thinking about for resource metering. Treating gas/budget as policy variables: WHEN gas_used > 800000 THEN complexity_score <= 50 // throttle expensive ops It's closer to metered execution than sandboxing, but fits the same formal verification approach. Current status: We're Python-only right now (Alpha v0.2). WASM compilation is Q2-Q3. Planning to: 1. Compile CSL to .wasm (no Python runtime needed) 2. Integrate as Wasmtime host function 3. Expose via Component Model interfaces If you're open to it, I'd love to pick your brain on the Component Model side when we get there. Your syscall isolation work + our semantic policy layer seem pretty complementary.

westurner 8mo ago
Flatpak manifests include a list of ACLs per app. Flatseal is one way to change the permissions granted to a flatpak. Restarting an app is required for permissions changes to take effect. Audit2allow and desbma/shh can generate policies. systrack, list-syscalls.rb, "B-Side: Binary-Level Static System Call Identification"; https://news.ycombinator.com/item?id=46726677 https://news.ycombinator.com/item?id=46726677 /? which linux lsm's allow online policy changes: https://www.google.com/search?q=which+linux+lsm%27s+allow+online+policy+changes https://www.google.com/search?q=which+linux+lsm%27s+allow+on... Writing to securityfs requires root privs. > for resource metering. Also for optimization with objective costs. > It's closer to metered execution than sandboxing, Linux cgroups support resource quotas. Systemd supports specifying per-unit resource quotas. /? what part of linux containers supports resource quotas? profiling? opcode counting? what part of linux containers supports resource quotas? profiling? opcode counting? >> Opcode Counting: This is typically done through hardware counters and kernel instrumentation, specifically using perf_events and eBPF (specifically tracepoints or kprobes Kernel docs > admin guide > perf_events: https://docs.kernel.org/admin-guide/perf-security.html https://docs.kernel.org/admin-guide/perf-security.html : > Usage of Performance Counters for Linux (perf_events) [1] , [2] , [3] can impose a considerable risk of leaking sensitive data accessed by monitored processes. How to mitigate such concerns with lower-level opcode counting for eWASM? Brendan Gegg's > perf examples: https://www.brendangregg.com/perf.html https://www.brendangregg.com/perf.html , and BPF/Perf book: https://www.brendangregg.com/bpf-performance-tools-book.html https://www.brendangregg.com/bpf-performance-tools-book.html I respectfully doubt that it's safe to trust runtime sandboxing. Containersec folks can probably explain why userspace filtering can never solve as well bubblewrap README > Sandboxing: https://github.com/containers/bubblewrap#sandboxing https://github.com/containers/bubblewrap#sandboxing arch wiki > Bubblewrap > Using portals; XDG Desktop Portal: https://wiki.archlinux.org/title/Bubblewrap#Using_portals https://wiki.archlinux.org/title/Bubblewrap#Using_portals > cloudflared/workerd: https://github.com/cloudflare/workerd https://github.com/cloudflare/workerd : >> WARNING: workerd is not a hardened sandbox wasmtime-mte requires support for ARM64 Memory Tagging Extensions.
westurner 8mo ago
> on the Component Model side when we get there. Your syscall isolation work + our semantic policy layer seem pretty complementary. I've hardly done any syscall isolation work. Though I have long wondered whether a userspace runtime/VM can ever be an effective sandbox. Sure. What about the Component Model?

westurner 8mo ago

Flatpak manifests include a list of ACLs per app. Flatseal is one way to change the permissions granted to a flatpak. Restarting an app is required for permissions changes to take effect. Audit2allow and desbma/shh can generate policies. systrack, list-syscalls.rb, "B-Side: Binary-Level Static System Call Identification"; https://news.ycombinator.com/item?id=46726677 https://news.ycombinator.com/item?id=46726677 /? which linux lsm's allow online policy changes: https://www.google.com/search?q=which+linux+lsm%27s+allow+online+policy+changes https://www.google.com/search?q=which+linux+lsm%27s+allow+on... Writing to securityfs requires root privs. > for resource metering. Also for optimization with objective costs. > It's closer to metered execution than sandboxing, Linux cgroups support resource quotas. Systemd supports specifying per-unit resource quotas. /? what part of linux containers supports resource quotas? profiling? opcode counting? what part of linux containers supports resource quotas? profiling? opcode counting? >> Opcode Counting: This is typically done through hardware counters and kernel instrumentation, specifically using perf_events and eBPF (specifically tracepoints or kprobes Kernel docs > admin guide > perf_events: https://docs.kernel.org/admin-guide/perf-security.html https://docs.kernel.org/admin-guide/perf-security.html : > Usage of Performance Counters for Linux (perf_events) [1] , [2] , [3] can impose a considerable risk of leaking sensitive data accessed by monitored processes. How to mitigate such concerns with lower-level opcode counting for eWASM? Brendan Gegg's > perf examples: https://www.brendangregg.com/perf.html https://www.brendangregg.com/perf.html , and BPF/Perf book: https://www.brendangregg.com/bpf-performance-tools-book.html https://www.brendangregg.com/bpf-performance-tools-book.html I respectfully doubt that it's safe to trust runtime sandboxing. Containersec folks can probably explain why userspace filtering can never solve as well bubblewrap README > Sandboxing: https://github.com/containers/bubblewrap#sandboxing https://github.com/containers/bubblewrap#sandboxing arch wiki > Bubblewrap > Using portals; XDG Desktop Portal: https://wiki.archlinux.org/title/Bubblewrap#Using_portals https://wiki.archlinux.org/title/Bubblewrap#Using_portals > cloudflared/workerd: https://github.com/cloudflare/workerd https://github.com/cloudflare/workerd : >> WARNING: workerd is not a hardened sandbox wasmtime-mte requires support for ARM64 Memory Tagging Extensions.

westurner 8mo ago

> on the Component Model side when we get there. Your syscall isolation work + our semantic policy layer seem pretty complementary. I've hardly done any syscall isolation work. Though I have long wondered whether a userspace runtime/VM can ever be an effective sandbox. Sure. What about the Component Model?