OpenClaw nicht als Root ausführen: Least Privilege, AppArmor und sichere Docker-Defaults
Das Signal von X: Endlich spricht jemand über Privilegiengrenzen
Die OpenClaw-Diskussionen heute teilen sich grob in zwei Lager.
Das laute Lager postet die üblichen „Agents sind die Zukunft“-Takes. Das nützlichere Lager spricht über das, was Betreiber wirklich brauchen: Gateway-Abstürze, fragile Setups und den Sicherheits-Fußschuss, den erstaunlich viele bei der Installation mitnehmen — OpenClaw als Root laufen zu lassen, weil es am Anfang bequemer war.
Das ist die falsche Voreinstellung.
Wenn dein Agent E-Mails lesen, Dateien anfassen, Shell-Kommandos ausführen, externe APIs aufrufen und Skills mit Tools benutzen kann, dann ist „einfach als Root starten“ keine Abkürzung. Es ist das Einreißen fast aller sinnvollen Sicherheitsgrenzen auf dem Host.
Gerade bei OpenClaw ist das relevant, weil es kein kleiner Chatbot in einer Browser-Tab ist. Es ist ein Ausführungssystem. Es kann über Discord, Telegram, Mail, Kalender, Dateisystem, Hintergrundprozesse, Browser-Automation und beliebige weitere Integrationen arbeiten. Sobald man es so betrachtet, gilt wieder die alte Linux-Regel: Der User, unter dem der Dienst läuft, definiert den maximalen Schaden.
Wenn dieser User Root ist, ist der maximale Schaden im Zweifel „die ganze Maschine“.
---
Warum Root so schlecht zu OpenClaw passt
Viele Self-Hoster greifen aus ziemlich banalen Gründen zu Root:
Genau deshalb bleibt es dann oft dauerhaft so. Aus dem kurzen Test wird ein echtes Deployment. Und plötzlich hat der Agent dauerhaft Zugriff auf alles.
Was bringt Root einem Angreifer, einem fehlerhaften Skill oder einer zu schnell bestätigten Exec-Freigabe?
Selbst wenn du dir selbst vertraust: Du solltest nicht jeder zukünftigen Anweisung, jedem kopierten Shell-Snippet, jedem externen Skill und jedem müden Klick auf „approve“ vertrauen.
Das praktische Modell ist simpel: OpenClaw sollte genug Rechte für seinen Job haben — und nicht mehr.
---
Das sichere Host-Setup: eigener User, eigener Workspace
Auf einem normalen Linux-Host ist das saubere Muster:
1. dedizierten Service-User anlegen
2. OpenClaw-Workspace diesem User gehören lassen
3. kein sudo innerhalb der Agent-Laufzeit
4. Secrets und Memory-Dateien hart absichern
5. nichts öffentlich exponieren, solange es nicht zwingend nötig ist
Minimales Beispiel:
<pre><code class="language-bash">sudo useradd --create-home --shell /bin/bash openclaw
sudo mkdir -p /home/openclaw/.openclaw
sudo chown -R openclaw:openclaw /home/openclaw/.openclaw
sudo chmod 700 /home/openclaw/.openclaw</code></pre>
Dann die Umgebungsdatei restriktiv absichern:
<pre><code class="language-bash">sudo chown openclaw:openclaw /home/openclaw/.openclaw/.env
sudo chmod 600 /home/openclaw/.openclaw/.env</code></pre>
Damit beseitigst du bereits einen der häufigsten Fehler: Secrets in einem zu offen lesbaren Verzeichnis, weil der Dienst schnell unter einem geteilten User hochgezogen wurde.
Wenn du systemd nutzt, sollte der Dienst explizit als dieser User laufen und nicht als Root:
<pre><code class="language-ini">[Service]
User=openclaw
Group=openclaw
WorkingDirectory=/home/openclaw/.openclaw/workspace
EnvironmentFile=/home/openclaw/.openclaw/.env
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=read-only</code></pre>
Je nach Layout musst du einzelne systemd-Hardening-Optionen etwas lockern. Die Richtung ist aber richtig: den Bereich verkleinern, den der Prozess überhaupt berühren kann.
---
Docker: Non-Root ist kein Nice-to-have
Docker macht viele Leute zu sorglos, weil „läuft im Container“ sicherer klingt, als es oft ist.
Ein Root-Prozess im Container ist immer noch ein Root-Prozess. Namespaces und cgroups helfen, aber sie sind keine magische Absolution. Falsch gesetzte Mounts, der Docker-Socket, zu breite Capabilities oder ein Container-/Kernel-Escape machen aus einem schlampigen Container schnell ein Host-Problem.
Für OpenClaw ist die sinnvolle Basis-Konfiguration deshalb:
Ein vernünftiger Compose-Ausschnitt sieht so aus:
<pre><code class="language-yaml">services:
openclaw:
image: ghcr.io/openclaw/openclaw:latest
user: "1001:1001"
read_only: true
tmpfs:
- /tmp
cap_drop:
- ALL
security_opt:
- no-new-privileges:true
- apparmor=openclaw-default
volumes:
- ./workspace:/home/openclaw/.openclaw/workspace
- ./env:/run/secrets
ports:
- "127.0.0.1:8080:8080"
restart: unless-stopped
mem_limit: 2g
pids_limit: 256</code></pre>
Das entscheidende Detail in der Port-Bindung ist <code>127.0.0.1:8080:8080</code> statt <code>0.0.0.0:8080:8080</code>. Damit ist der Dienst lokal erreichbar, aber nicht automatisch aus dem ganzen Netz.
Diese eine Zeile verhindert erstaunlich viele versehentliche Exposures.
---
AppArmor: die zusätzlichen 10 Minuten lohnen sich
Wenn du auf Ubuntu oder einer anderen AppArmor-fähigen Distribution läufst, nutze es.
AppArmor ist nicht glamourös. Genau deshalb ist es wertvoll. Du definierst auf Kernel-Ebene, was ein Prozess lesen, schreiben und ausführen darf. Wenn OpenClaw eine schlechte Anweisung bekommt oder ein Tool Unsinn macht, hast du damit eine weitere Bremse im System.
Du brauchst dafür nicht am ersten Tag ein perfektes Profil. Schon ein solides Profil, das Schreibzugriffe auf den Workspace begrenzt und unerwartete Ausführungspfade einschränkt, ist viel besser als „hoffentlich passiert nichts“.
Konzeptionell sollte dein Profil:
Wenn du AppArmor noch nie benutzt hast: erst im Complain-Mode starten, beobachten, was der Dienst wirklich braucht, dann schrittweise auf Enforce umstellen.
Der Punkt ist nicht, ein unknackbares Gefängnis zu bauen. Der Punkt ist, dass ein Fehler spürbar weniger teuer wird.
---
Exec: Hier werden Privilegienfehler zu echten Vorfällen
Fast jede OpenClaw-Sicherheitsdiskussion landet irgendwann hier, weil das der Punkt ist, an dem aus „AI-Assistent“ ganz klar „Remote Operator“ wird.
Wenn Exec verfügbar ist und der Prozess als Root läuft, dann wird aus jeder falschen Freigabe eine Root-Freigabe.
Damit verändert sich das gesamte Risikoprofil.
Das sichere Muster ist:
Anders gesagt: Least Privilege und Approval-Modus ergänzen sich. Freigabedialoge ersetzen keine sauberen Unix-Rechte. Sie sind der zweite Sicherheitsgurt, nicht der erste.
---
Netzwerkregel: Standardmäßig null öffentliche Ports
Für die meisten OpenClaw-Installationen gilt eine langweilige, aber richtige Regel: Das Gateway nicht direkt ins öffentliche Internet stellen.
Stattdessen:
Vermeide die Denkweise „ich öffne nur kurz einen Port“. Agents sind komplexe Systeme mit vielen Integrationen. Genau solche Systeme stellt man nicht nebenbei offen ins Netz.
Wenn du wirklich Webhooks brauchst, dann über einen minimalen öffentlichen Endpoint, der Signaturen validiert und nur die konkret erwarteten Events weiterleitet. Das komplette Agent-Gateway sollte nicht zum Public Web Service werden.
---
15-Minuten-Audit: sofort prüfen
Wenn OpenClaw schon läuft, prüfe zuerst diese Punkte:
1. Unter welchem User läuft der Prozess?
2. Hört das Gateway auf localhost oder auf allen Interfaces?
3. Sind Workspace und <code>.env</code> nur für den Service-User lesbar?
4. Läuft der Container als Root?
5. Gibt es unnötige Bind-Mounts?
6. Macht AppArmor oder ein anderes MAC-System überhaupt irgendetwas?
Nützliche Kommandos:
<pre><code class="language-bash">ps -o user,pid,cmd -C node
ss -tulpn | grep openclaw
stat -c "%U %G %a %n" /home/openclaw/.openclaw /home/openclaw/.openclaw/.env
docker inspect openclaw --format '{{.Config.User}}'</code></pre>
Wenn die Antworten Root, Public Bind, lockere Dateirechte und keinerlei Confinement lauten, ist klar, was als Nächstes zu tun ist.
---
TL;DR
Der beste OpenClaw-Hardening-Schritt ist nicht exotisch.
Sondern dieser:
So wird aus OpenClaw nicht nur eine coole Demo mit fragwürdigen Rechten, sondern ein System, das man ruhiger dauerhaft laufen lassen kann.
Wenn dein aktuelles Setup nur deshalb funktioniert, weil es Root ist, dann ist das kein robustes Setup. Das ist aufgeschobenes Aufräumen mit zusätzlichem Risiko. Lieber jetzt sauber machen, bevor etwas brennt.