Zum Inhalt

MCP – Audit-Integrität

Stand 08.09.2026: produktiv installiert und geprüft. Die Audit-Dateien auf CT 108 werden jetzt nicht mehr direkt vom unprivilegierten Benutzer mcp geschrieben. Stattdessen nimmt ein lokaler Root-Writer ausschließlich bereits minimierte Audit-v2-Ereignisse über einen Unix-Socket entgegen und schreibt sie in root-eigene Tagesdateien. Cloudflare, Tunnel, Netzwerk und Remotezugang wurden nicht verändert.

Ziel

Vor der Umstellung schrieb der Benutzer mcp die Audit-Dateien selbst. Damit konnte derselbe Prozess, der neue Einträge erzeugt, seine bisherigen Protokolle grundsätzlich auch verändern oder löschen. Die bereits installierte Audit-v2-Inhaltsbegrenzung schützte vor Geheimnissen im Protokoll, aber noch nicht vor nachträglicher Manipulation.

Die produktive Trennung lautet jetzt:

  • /var/log/mcp-audit/ ist root:mcp mit Modus 0750.
  • Tagesdateien sind root:mcp mit Modus 0640.
  • mcp darf die Logs lesen, aber nicht mehr direkt schreiben, kürzen, löschen oder im Audit-Verzeichnis neue Dateien anlegen.
  • mcp-audit-writer.service läuft lokal als root und hängt neue, bereits minimierte Audit-v2-Ereignisse über /run/mcp-audit-writer/audit.sock an die Tagesdatei an.
  • Der Writer akzeptiert nur das streng begrenzte Audit-v2-Schema. Unbekannte Felder, Rohbefehle, freie Fehlertexte und veraltete Zeitstempel werden abgewiesen.
  • Die bestehende 7-Tage-Aufbewahrung wird vom Root-Writer übernommen.

Sicherheitsgrenze

Der Writer führt keinerlei Befehle aus und verarbeitet keine freien Dateipfade. Der Socket ist für root:mcp vorgesehen. Ein kompromittierter MCP kann weiterhin falsche neue aktuelle Ereignisse erzeugen oder durch viele gültige Ereignisse die Protokollierung belasten. Er kann nach der Umstellung jedoch vorhandene Audit-Dateien nicht mehr direkt verändern oder entfernen. Root auf CT 108 bleibt ausdrücklich außerhalb dieses Schutzmodells.

Ausfallsverhalten

Ist der lokale Writer nicht erreichbar, wird die eigentliche MCP-Aktion weiterhin nicht erneut ausgeführt. Der Audit-Sink meldet nur einen festen Fehlercode im Journal. Es gibt keinen Rückfall auf ungefilterte Rohdaten. Damit werden Doppelaktionen und eine versehentliche Rückkehr zur früheren Inhaltsprotokollierung vermieden.

Installerprüfungen und sichere Abbrüche

Vor dem erfolgreichen Deployment gab es drei sichere Abbrüche im separaten Root-Schutztest. Alle drei geschahen vor Backup, Dienststop und produktiver Dateiänderung. MCP und Admin blieben dabei aktiv, bestehende Audit-Dateien unverändert mcp-eigen und mcp-audit-writer.service wurde nicht installiert.

Die Ursachen waren ausschließlich Testaufbau-Probleme:

  1. Der erste Test wartete nur auf das Vorhandensein des Unix-Sockets, nicht auf dessen finalen Eigentümer root:mcp und Modus 0660.
  2. Die R2-Fassung wartete korrekt auf den Socket, aber das temporäre Root-Testverzeichnis war für mcp nicht traversierbar.
  3. Die R3-Fassung setzte das äußere Testverzeichnis auf 0755, berücksichtigte aber noch nicht, dass der Installer mit umask 077 läuft und das darunter angelegte run-Verzeichnis dadurch effektiv 0700 blieb.

R4 setzt deshalb nach mkdir() ausdrücklich chmod(run, 0755). Das betrifft ausschließlich das Wegwerf-Testverzeichnis. Die produktiven Schutzrechte wurden dadurch nicht abgeschwächt.

Erfolgreiches Deployment mit R4

Der erfolgreiche Installerlauf mit /tmp/mcp-audit-integrity-20260908-r4.tar.gz bestätigte:

  • internes Dateimanifest vollständig gültig;
  • bestehende Audit-Dateien regulär und vor der Umstellung mcp-eigen;
  • 9/9 fokussierte Integritätstests bestanden;
  • unprivilegierter Socket-Test erfolgreich; Rohinhalt wurde vor dem Transport entfernt;
  • Root-Schutztest erfolgreich: mcp kann die root-eigene Audit-Datei weder anhängen, kürzen oder löschen noch neue Dateien im Audit-Verzeichnis anlegen;
  • bestehende Policy gültig, 0 gesperrte Tools;
  • unveränderte Schutzdateien, Admin-Dateien, command-runner.js, Tool-Freigaben und Shell-Flag per Prüfsummen bestätigt;
  • mcp-audit-writer.service installiert und aktiviert;
  • unauthentifizierter Zugriff auf MCP und Admin weiterhin jeweils 401;
  • mcp-audit-writer, mcp-shell und mcp-admin nach dem Deployment aktiv.

Rollback:

/root/mcp-audit-integrity-backup-20260908T111028Z.uJUjdq/rollback.sh

Tests und Deployment:

/root/mcp-audit-integrity-20260908-r4.osWrqI

Isolierte Testkopie:

/tmp/mcp-audit-integrity-test.y3Ng2N

Ein produktiver Rollback war nicht erforderlich und wurde nicht ausgeführt.

Produktive Live-Prüfung

Nach dem Deployment wurden echte MCP-Aufrufe durchgeführt:

  • get_service_status für mcp-audit-writer: execution_status: succeeded, exit_code: 0, completion: exit_observed.
  • get_service_status für mcp-shell: ebenfalls erfolgreich mit Exitcode 0.
  • get_service_status für mcp-admin: ebenfalls erfolgreich mit Exitcode 0.
  • Die zugehörigen neuen Audit-v2-Einträge wurden anschließend über get_audit_logs gelesen. Sie enthalten die erwarteten minimierten Metadaten einschließlich Exitcode und Prozessstatus, aber keine Rohbefehle oder freie Ausgabeinhalte.

Damit ist sowohl der neue Root-Writer als auch der weiterhin funktionierende produktive Audit-Lesepfad nachgewiesen.

Nicht betroffen

Nicht verändert wurden:

  • Cloudflare und der Tunnel;
  • Netzwerk und Remotezugang;
  • Admin-Authentifizierung;
  • Tool-Freigaben und Policy-Schema;
  • Wiki-Härtung;
  • shell_execute-Flag;
  • bestehende Audit-Inhalte.

Die Shell-Wartungsfreigabe war bei der Abschlusskontrolle weiterhin aktiv und sollte nach Abschluss der Wartung über die Admin-Oberfläche wieder gesperrt werden.