This document describes the security architecture of mcp-podman-crunchtools.
| Asset | Sensitivity | Impact if Compromised |
|---|---|---|
| Podman Socket Access | Critical | Full container/host control |
| Container Data | High | Data exfiltration, manipulation |
| Host Filesystem (via mounts) | High | Arbitrary file access |
| Vector | Description | Mitigation |
|---|---|---|
| Socket Hijacking | Unauthorized socket access | Unix file permissions |
| Container Escape | Break out of container | Rootless Podman, SELinux |
| Input Injection | Malicious container names | Pydantic validation |
| Resource Exhaustion | Create unlimited containers | Rate awareness |
| Supply Chain | Compromised dependencies | Automated CVE scanning |
- Layer 1 — Input Validation: Pydantic models with
extra="forbid"and field limits - Layer 2 — Socket Security: Unix permissions (no network exposure)
- Layer 3 — API Client: Request timeouts, response size limits
- Layer 4 — No Shell Execution: Pure HTTP API calls, no subprocess/eval/exec
- Layer 5 — Supply Chain: Weekly CVE scanning, Hummingbird base images
Unlike HTTP API servers, this server uses Unix socket file permissions for authentication. Access to the Podman socket grants full Podman API access. The server does not add any additional authentication layer.
When running in a container with the host Podman socket mounted:
- Use
--security-opt label=type:container_runtime_t - Mount socket with
:zrelabel flag
Report vulnerabilities using GitHub's private security advisory.
Do NOT open public issues for security vulnerabilities.