Linux Sandboxes and Fil-C

Fil-C’s goals vs existing tools (ASan, sudo-like tools)

• Fil-C aims to make existing C/C++ binaries memory-safe at runtime by turning memory errors into panics, not silent corruption or RCE.
• Commenters stress ASan is only a bug-finding tool with false negatives and is explicitly not for production; attackers can still get RCE under ASan.
• Fil-C is seen as promising for hardening legacy tools like sudo/polkit and for testing codebases to surface subtle bugs. A Nix integration exists, though not yet upstreamed.

Memory safety vs sandboxing (seccomp, WASM, VMs, Landlock)

• Thread distinguishes “memory safety” (constraining what memory a bug can touch) from “sandboxing” (constraining what the compromised process can do).
• Seccomp is considered powerful but painful: architecture/libc sensitive, hard to compose across libraries, and blind to paths. Best suited for application-specific policies, not language-level defaults.
• MicroVMs and full VMs are praised as strong sandboxes but often too heavyweight for per-tab/per-connection isolation; OS-level sandboxing plus privilege separation is usually preferred.
• WASM is widely characterized as sandboxing, not memory safety: bugs still let attackers control all memory inside the guest. Some point out partial safety (protected stack, typed indirect calls) and future WasmGC, but consensus is that it mainly protects the host.
• Landlock is briefly mentioned; one commenter dismisses it, another notes it works fine with Fil-C but isn’t used in the example ecosystems.

Rust, Go, and Fil-C tradeoffs

• Rust enforces most safety statically, with unsafe as an explicit escape hatch; Fil-C enforces safety dynamically with runtime checks and a GC, trading some performance.
• Fil-C is pitched as ideal for existing C where rewrites are infeasible; Rust is favored for new codebases that can accept its type system and borrow checker.
• Some argue that combining Fil-C with OS sandboxing could allow more “unfettered” system access than WASM-based sandboxes.

Data races, capabilities, and trust

• A long subthread debates Fil-C’s handling of torn pointer writes under data races, where a pointer’s numeric value and its capability may momentarily mismatch.
• One side argues this can violate intuitive “pointer == object” reasoning and is weaker than JVM/Rust models; the other argues Fil-C’s formal memory-safety definition is capability-based and still prevents full “weird execution” and arbitrary memory control.
• Beyond the technical dispute, some commenters are uneasy about perceived defensiveness and “big claims,” while others feel the criticism shades into FUD and that limitations are in fact documented.

Performance, scope, and ecosystem

• Fil-C’s GC and checks can cause noticeable slowdowns in some workloads; it targets “non–perf-critical but security-critical” C/C++ more than high-performance new systems programming.
• Shared-memory designs (e.g., certain web servers and databases) are noted as challenging for Fil-C today.
• Several commenters see Fil-C as complementary to Rust/Go and to traditional sandboxes, not a universal replacement.

Miscellaneous

• Some discussion about naming the project after its creator; most consider it harmless or even convenient for namespacing.
• Minor nitpicking over use of “orthogonal” for memory safety vs sandboxing, with agreement they’re distinct but not fully unrelated.