Vendor claims Aider can safely run shell commands. I don't trust it. A compromised prompt or a rogue model response could execute `rm -rf /` or exfiltrate data.
Here's a bare-minimum sandbox approach I use. It's not foolproof, but it forces explicit approval.
* Create a dedicated, unprivileged user with no home directory: `sudo useradd -r -s /bin/bash aider_runner`
* Use `chroot` or a minimal container (Docker/Podman) to limit filesystem access. Map only the project directory.
* Restrict shell commands via a wrapper script. Aider's `--yes-to-prompts` is dangerous. Instead, intercept commands.
* Parse Aider's output for code blocks starting with `bash` or `sh`.
* Log every command. Require manual approval via a separate terminal or a prompt.
* Only then execute as the restricted user.
Key pitfalls:
* This adds friction. It breaks the "flow" vendors love to sell.
* You must audit the model's suggested commands constantly. No auto-approval.
* The sandbox must have no network access unless explicitly required for the task.
Has anyone implemented a stricter seccomp profile or AppArmor rules for this specific use case? I want to see the vendor's recommended security protocol in writing. Their docs are silent on real containment.
Your chroot/useradd approach is the right starting point for a threat model that assumes the model itself is adversarial. I've moved to Kubernetes pods for this because you can compose security contexts declaratively. A Pod spec with a read-only root filesystem, a non-root user, and a drop-all seccomp profile gets you 80% there.
But the real gap is the "manual approval" step. Parsing STDOUT for code blocks is brittle; Aider's output format could change. A more deterministic method is to use Aider's `--command` flag to pipe its suggested commands through a sanitizer script before execution. That script can enforce a whitelist of allowed commands (like `git`, `npm`, `make`) and reject anything with `rm`, `curl`, or `wget`.
For a stricter confinement, here's an AppArmor profile fragment I've used for similar "untrusted automation" workloads. It denies network, raw socket access, and writes outside the specific mounted project directory.
```
#include
profile aider-scoped flags=(attach_disconnected) {
#include
#include
#include
# Deny network
deny network,
# Allow reading the toolchain and project dir
/projects/** r,
/usr/bin/** rx,
/bin/** rx,
# Deny everything else, especially writes outside project
deny /** w,
/projects/** rw,
}
```
The problem, as you noted, is this destroys the flow. The overhead of crafting and maintaining these profiles often outweighs the risk for most internal projects. I only go this far for CI/CD systems running on shared clusters.
The manual approval step you're describing is a major operational bottleneck. It trades one risk for another, human error and fatigue. Your wrapper script parsing code blocks is itself a large attack surface.
You're right about network access, but a strict seccomp profile and mandatory access control (AppArmor/SELinux) are non-negotiable for any "secure" claim. A vendor recommendation without these is just marketing.
secure by default, not by audit