fix: restrict docker commands for ai-worker user
Remove ai-worker from docker group and enforce sudo whitelist. SECURITY: Being in the docker group gives unrestricted access to the Docker daemon socket (/var/run/docker.sock), allowing any docker command: docker exec, docker cp, docker run -v /:/host, docker commit, etc. Changes: - Remove extraGroups = ["docker"] from ai-worker user definition - Add comprehensive sudo NOPASSWD whitelist for safe docker subcommands ALLOWED: ps, inspect, logs, images, info, version, stats, start, stop, restart, rm, rmi, wait, pull, build, run, compose, system, network ls, volume ls BLOCKED (implicitly): exec, cp, commit, diff, export, import, load, save, attach, push, tag, create, plugin, network create, volume create - Update ai-worker-restricted.nix module to reflect new approach - Update README-ai-worker.md with new security model and examples All docker commands must now be prefixed with sudo. The Hermes agent's host_run tool needs to be updated to prepend sudo.
This commit is contained in:
@@ -1,10 +1,44 @@
|
||||
# AI Worker Restricted Access
|
||||
|
||||
This module provides SSH access for the AI worker (hermes-agent) to run ollama benchmarks on the host.
|
||||
This module provides SSH access for the AI worker (hermes-agent) to run docker commands on the host.
|
||||
|
||||
## Security Model
|
||||
|
||||
The `ai-worker` user has:
|
||||
### Overview
|
||||
|
||||
The `ai-worker` user has **no direct docker group access**. All docker commands must go through `sudo`, and only specific subcommands are whitelisted:
|
||||
|
||||
- **Container lifecycle**: `docker ps`, `docker inspect`, `docker logs`, `docker images`, `docker info`, `docker version`, `docker stats`
|
||||
- **Control**: `docker start`, `docker stop`, `docker restart`, `docker rm`, `docker rmi`, `docker wait`
|
||||
- **Image management**: `docker pull`, `docker build`, `docker run`, `docker compose`
|
||||
- **Disk cleanup**: `docker system`
|
||||
- **Network/Volume**: `docker network ls`, `docker volume ls` (read-only)
|
||||
|
||||
### EXPLICITLY BLOCKED (not in sudo whitelist)
|
||||
|
||||
| Command | Risk | Result |
|
||||
|---------|------|--------|
|
||||
| `docker exec` | Execute arbitrary commands inside containers (FILE MODIFICATION) | Blocked by sudo |
|
||||
| `docker cp` | Copy files between containers and host | Blocked by sudo |
|
||||
| `docker commit` | Create images from running containers (data exfil) | Blocked by sudo |
|
||||
| `docker diff` | Inspect filesystem changes | Blocked by sudo |
|
||||
| `docker export` | Export container filesystem | Blocked by sudo |
|
||||
| `docker import` | Import filesystem archives | Blocked by sudo |
|
||||
| `docker load` | Load docker images | Blocked by sudo |
|
||||
| `docker save` | Save docker images to tar | Blocked by sudo |
|
||||
| `docker attach` | Interactive access to containers | Blocked by sudo |
|
||||
| `docker push` | Push images to registries | Blocked by sudo |
|
||||
| `docker tag` | Rename images | Blocked by sudo |
|
||||
|
||||
### Why This Approach?
|
||||
|
||||
Previously, `ai-worker` was a member of the `docker` group, which gives **unrestricted** access to the Docker daemon socket (`/var/run/docker.sock`). Users in the `docker` group can run ANY docker command, including:
|
||||
|
||||
- `docker exec -it container bash` — full shell access to any container
|
||||
- `docker cp /host/file container:/path` — file modification inside containers
|
||||
- `docker run -v /:/host alpine` — full host filesystem access
|
||||
|
||||
By removing the `docker` group and using a sudo whitelist instead, we enforce the principle of least privilege.
|
||||
|
||||
### Filesystem Access
|
||||
- **Home directory**: `/home/ai-worker` (standard user home)
|
||||
@@ -12,51 +46,33 @@ The `ai-worker` user has:
|
||||
- **Cannot access**: Any files outside standard system paths
|
||||
|
||||
### Sudo Access
|
||||
- **NONE**: ai-worker has no sudo privileges
|
||||
- **Restricted**: ai-worker has `NOPASSWD` access only to whitelisted commands
|
||||
- Cannot run `nh`, `nixos-rebuild`, `nixpkgs-fmt`, or `nix` with elevated permissions
|
||||
|
||||
### Docker Access
|
||||
- Member of `docker` group - can run `docker` and `docker exec` commands
|
||||
- Primary use: `docker exec ollama ollama ...` for benchmarking
|
||||
- Can run `docker exec --privileged ollama rocm-smi ...` for VRAM monitoring
|
||||
## Workflow: SSH + Restricted Docker
|
||||
|
||||
## Workflow: SSH + Docker Benchmarking
|
||||
|
||||
The AI worker connects from the Hermes container to the host via SSH, runs ollama benchmarks, then returns to save results.
|
||||
|
||||
### Example Workflow
|
||||
All docker commands must be prefixed with `sudo`:
|
||||
|
||||
```bash
|
||||
# From Hermes container, SSH to host
|
||||
ssh -i /path/to/ssh/key ai-worker@host.docker.internal
|
||||
|
||||
# On host, run ollama benchmarks via docker
|
||||
docker exec ollama ollama pull devstral-small-2:24b
|
||||
# Check container status (works)
|
||||
sudo docker ps
|
||||
|
||||
# Create test modelfile
|
||||
docker exec ollama bash -c 'cat <<EOF > /root/.ollama/test.modelfile
|
||||
FROM devstral-small-2:24b
|
||||
PARAMETER num_ctx 65536
|
||||
PARAMETER num_gpu 99
|
||||
PARAMETER flash_attn true
|
||||
EOF'
|
||||
# Restart a container (works)
|
||||
sudo docker restart ollama
|
||||
|
||||
# Create and test model
|
||||
docker exec ollama ollama create test-model -f /root/.ollama/test.modelfile
|
||||
docker exec ollama ollama run test-model "Write a Python async function"
|
||||
# Run benchmark (works - docker run is allowed)
|
||||
sudo docker run --rm alpine echo "test"
|
||||
|
||||
# Check VRAM usage
|
||||
docker exec --privileged ollama rocm-smi --showmeminfo vram
|
||||
# ANY of these will FAIL (not in whitelist):
|
||||
sudo docker exec ollama ollama list # FAILS - docker exec blocked
|
||||
sudo docker cp file.txt container:/path/ # FAILS - docker cp blocked
|
||||
sudo docker commit container new-image # FAILS - docker commit blocked
|
||||
|
||||
# Cleanup
|
||||
docker exec ollama ollama rm test-model
|
||||
|
||||
# Exit SSH, return to Hermes container
|
||||
exit
|
||||
|
||||
# Save results in Hermes container
|
||||
# /opt/data/ai-optimizer/state.json
|
||||
# /opt/data/ai-optimizer/results.csv
|
||||
# For ollama operations, use the HTTP API instead of docker exec:
|
||||
curl http://ollama:11434/api/tags
|
||||
```
|
||||
|
||||
## SSH Access
|
||||
@@ -74,25 +90,30 @@ Check ai-worker permissions:
|
||||
```bash
|
||||
# On the host, as root or gortium:
|
||||
sudo -u ai-worker sudo -l
|
||||
# Should show: no sudo access
|
||||
# Should show the whitelisted commands only (no docker exec/cp/commit)
|
||||
|
||||
# Check docker group membership
|
||||
# Verify NOT in docker group
|
||||
groups ai-worker
|
||||
# Should show: ai-worker docker
|
||||
# Should show: ai-worker (NO docker group)
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If ai-worker cannot run docker commands:
|
||||
If docker commands fail:
|
||||
|
||||
```bash
|
||||
# Check docker group membership
|
||||
# Check sudo permissions
|
||||
sudo -u ai-worker sudo -l | grep docker
|
||||
|
||||
# Verify group membership
|
||||
groups ai-worker
|
||||
|
||||
# Verify ollama container is running
|
||||
docker ps | grep ollama
|
||||
# Test allowed command
|
||||
sudo -u ai-worker sudo docker ps
|
||||
|
||||
# Test docker access
|
||||
sudo -u ai-worker docker exec ollama ollama list
|
||||
# Test blocked command (should fail)
|
||||
sudo -u ai-worker sudo docker exec ollama ollama list
|
||||
# Expected: "Sorry, user ai-worker is not allowed to execute"
|
||||
```
|
||||
|
||||
If SSH connection fails:
|
||||
|
||||
Reference in New Issue
Block a user