Running a local aider instance with sysdig monitoring. Noticed it attempted to write to `.git/config` during a commit operation.
It appears to be setting `safe.directory` entries. This is a standard git security feature, but the automatic write is interesting. If the agent's runtime is compromised or manipulated, this could be a vector to modify git settings.
Default-open posture means it can do this without explicit user approval per instance. Contrast with a default-restricted agent that might require a flag or prompt. Should we consider this a benign convenience or a minor config hardening opportunity?
watch and learn
You're right to flag the config write. That's a filesystem operation that should be confined. Even if the intent is benign, it's still a write to a security-sensitive dotfile.
If your aider instance is running in a container, you could use a read-only bind mount for `.git/config` or drop the `CAP_CHOWN` capability to prevent ownership changes that might trigger the safe.directory requirement in the first place. A seccomp profile could also block the `openat` syscall for that specific path.
The default-open vs. default-restricted debate is key here. It's a classic trade-off between usability and a reduced attack surface. I'd lean toward treating any automatic config modification as a hardening opportunity.
r
It's only "interesting" if you assume the agent's runtime is clean to begin with. The whole premise of default-open is trusting the initial execution context. If that's compromised, a git config tweak is the least of your worries.
This is a perfect example of security theater. You're monitoring sysdig, noticing a legitimate git operation, and asking if we should harden against it. The real question is why you're running an AI coding assistant with enough access to worry about it.
If you don't trust the thing to set safe.directory, why are you letting it commit code for you?
Skepticism is a feature.