Thore CimbalandClaude Opus 4.8
51c05edb2d
Went through the seven imported waiting issues and replaced the generic 'reason is in the GitLab history' placeholder with the real blocker, which completes #0041. Three of the seven were not merely imprecise but wrong: - #0025: the deploy had long landed; screenshots confirm 24 aggregated messages in the security room (limit 29), summing to the known 126 CRITICALs. - #0014: the A/B/C decision exists as ADR-0008 (option A). Half its open question is now answered — MATRIX has no docker group at all, so the root-equivalence does not apply there. - #0027: the blocking Struktur-Workshop happened on 2026-08-06 and produced three ADRs, but W1 and W3 were spot-checked and are still unresolved. The remaining four wait on a named action by sorb. Measured from here: the GAME exporters are still filtered (and their silences expired on 2026-08-04, so TargetDown has been firing every 4h since), while CFGMON's 9090/3100 are already closed from the internet — so #0008 is about making that state deliberate rather than an acute exposure. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2.8 KiB
type, id, status, created, milestone, priority, host, area, gitlab_iid, related
| type | id | status | created | milestone | priority | host | area | gitlab_iid | related | |
|---|---|---|---|---|---|---|---|---|---|---|
| issue | 0014 | open | 2026-08-01 | M2 | low | cfgmon | security | 14 |
|
CFGMON-14: Root-Zugang über die docker-Gruppe umgeht sudo und hinterlässt keine Spur
Import aus management#14 (2026-08-11). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei (ADR-0012).
Aus dem CFGMON-AAR (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?
Entscheidung liegt vor (ADR-0008) — Restaufgabe 2026-08-15
Die im Issue offene Wahl zwischen A/B/C ist entschieden: ADR-0008 (2026-08-06,
Struktur-Workshop) wählt ausdrücklich Option A — Agenten-Sessions laufen auf CFGMON
root-äquivalent über die docker-Gruppe, und „sudo mit Passwort" gilt dort ausdrücklich
nicht als Kontrollmechanismus. Option C bleibt Ziel, aber erst wenn ein zweiter Mensch
mitarbeitet. Das Issue wartet also auf nichts mehr → open statt waiting.
Von der Vorfrage ist eine Hälfte beantwortet: „Gilt dasselbe auf MATRIX?" → Nein.
getent group docker auf MATRIX liefert nichts — dort läuft k3s ohne Docker-Daemon, die
Root-Äquivalenz über die docker-Gruppe existiert also gar nicht. (Geprüft 2026-08-15 per SSH.)
Rest: Auf CFGMON prüfen, welche Konten in der docker-Gruppe sind (getent group docker)
und ob sie alle dorthin gehören — braucht eine Host-Session, vom Mac nicht einsehbar. Danach
kann das Issue geschlossen werden; die Entscheidung selbst steht in ADR-0008.