---
type: issue
id: "0014"
status: waiting
created: 2026-08-01
milestone: M2
priority: low
host: cfgmon
area: security
wartegrund: Grund im GitLab-Verlauf benannt (Import 2026-08-11); im nächsten Refinement präzisieren
gitlab_iid: "14"
related: []
---
# CFGMON-14: Root-Zugang über die docker-Gruppe umgeht sudo und hinterlässt keine Spur

> Import aus [management#14](https://git.lab/axion1337.chat/management/-/issues/14) (2026-08-11). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei (ADR-0012).

Aus dem [CFGMON-AAR](https://git.lab/axion1337.chat/management/-/blob/main/verfahren/aar/2026-08-01-labnet02-cfgmon.md) (Befund 3, MEDIUM), Entscheidung liegt bei sorb.

`sudo` ist aus einer Agenten-Session nicht bedienbar (kein TTY: *„a terminal is required to read the password"*). Die LABNET-02-Schritte liefen deshalb über die **docker-Gruppenmitgliedschaft** des Kontos `rantanplan` — privilegierter Container plus `nsenter` in die Host-Namespaces. Das ist **root-äquivalent**.

**Konsequenz:** Die sudo-Passwortabfrage ist für dieses Konto keine wirksame Sicherheitsgrenze, und dieser Weg hinterlässt **keinen Eintrag in `auth.log`**. Auf Linux ist das normales Verhalten der docker-Gruppe und kein Konfigurationsfehler — aber es sollte eine bewusste Entscheidung sein.

**Optionen:**
- **A — so lassen**, aber dokumentieren (dann ist „sudo mit Passwort" auf diesem Host explizit kein Kontrollmechanismus mehr)
- **B — Konto aus der docker-Gruppe nehmen** und Docker-Zugriff über eine gezielte sudo-Regel führen (auditierbar, aber Agenten-Sessions brauchen dann einen anderen Weg)
- **C — getrenntes Konto** für Agenten-Sessions mit definierter, protokollierter Rechteerhöhung

Vor einer Entscheidung zu klären: Welche anderen Konten sind in der docker-Gruppe, und gilt dasselbe auf MATRIX?