Wie richte ich meinen Rechner ein, damit ein Modell meine Passwörter nicht lesen kann?
Die Einrichtung Ihres Rechners entscheidet, nicht der Server. Die drei Stufen (kompromisslos, normal, leichtsinnig) nebeneinander mit dem, was jede schließt und kostet, dann die Schritte der Reihe nach mit der echten Ausgabe jedes Befehls und der Befehl, der das Ergebnis prüft.
Inhalt
Die kurze Antwort: Die Einrichtung Ihres Rechners entscheidet
Ob ein Modell Ihre Passwörter lesen kann, entscheidet sich an der Einrichtung Ihres Rechners, nicht am Server. Der Server schließt die Wege, die er schließen kann: Der Wert eines Zugangsdatums erscheint nie in einem Werkzeugergebnis, im Journal oder auf einer Befehlszeile; er wird nur auf dem Ursprung getippt, an den er gebunden ist; eine Zahlung, eine Löschung oder eine Änderung eines Geheimnisses wartet auf Ihre Bestätigung. Ein Modell, das zusätzlich eine Shell hat, ist etwas anderes. Es erreicht alles, was sein Konto erreicht: Läuft es unter dem Konto, das Ihr verschlüsseltes Verzeichnis hält, listet es die Dateien dort auf, spricht den Browser über seinen Debugging-Port an und schreibt das Profil um, dem der Server gehorcht. Keine Prüfung im Server kann verweigern, was das System erlaubt.
Eine Regel in einer Konfigurationsdatei kann ein Modell mit einer Shell ändern. Eine Verweigerung durch das Betriebssystem, weil die Datei einem anderen Konto gehört, kann es nicht. Sie wählen unter drei Stufen, wie viel das System verweigern soll: kompromisslos, normal und leichtsinnig (nicht empfohlen). Die Schritte bauen sie in umgekehrter Reihenfolge auf, vom vorhandenen Rechner bis zur strengsten Stufe. Diese Seite stellt die drei nebeneinander und gibt dann für jede die Schritte der Reihe nach, jeden Befehl mit seiner echten Ausgabe, und die Prüfung, die sagt, wo Ihr Rechner steht.
Kurz gesagt: Nur die kompromisslose Stufe schließt das Abgreifen dessen, was Sie tippen, und sudo. Die normale Stufe schließt das verschlüsselte Verzeichnis, das Browserprofil, den Debugging-Port und das Journal, aber nicht das Konto, unter dem das Modell läuft. Die leichtsinnige Stufe schließt nichts: Sie ist der Zustand eines Rechners, auf dem nichts gewählt wurde.
Die drei Stufen nebeneinander
Eine Stufe ist eine Eigenschaft des Rechners, keine Einstellung des Servers. Sie hängt davon ab, welches Konto das verschlüsselte Verzeichnis, den Browser und den Server hält und unter welchem Konto das Modell läuft.
| Stufe | Unter Ihrem Konto | Unter diwall-mcp | Unter agent |
|---|---|---|---|
| Kompromisslos | Ihr Bildschirm, die Bestätigungsfenster, die Administration | das verschlüsselte Verzeichnis, das Browserprofil, der Browser, der Server | der MCP-Client und das Modell |
| Normal | der MCP-Client und das Modell, Ihr Bildschirm, die Bestätigungsfenster | das verschlüsselte Verzeichnis, das Browserprofil, der Browser, der Server | nichts |
| Leichtsinnig (nicht empfohlen) | alles | nichts | nichts |
| Stufe | Schließt | Lässt offen | Kostet |
|---|---|---|---|
| Kompromisslos | alle zehn Wege: neun durch den Kernel, Weg 4 durch den Server | keinen | ein weiteres Konto (agent), in dessen Home-Verzeichnis alles landet, was das Modell schreibt |
| Normal | die Wege 1, 2, 3, 5, 6 und 8 durch den Kernel, Weg 4 durch den Server | die Wege 7, 9 und 10 | ein Konto (diwall-mcp), eine systemd-Unit und eine Firewall-Regel |
| Leichtsinnig (nicht empfohlen) | nichts durch den Kernel | neun Wege von zehn; der zehnte hat keinen Gegenstand | nichts |
- Kompromisslos verlegt den Client und das Modell auf ein drittes Konto. Es erreicht weder Ihren Bildschirm noch Ihre Startdateien noch Ihre Administratorrechte.
- Normal verlegt das verschlüsselte Verzeichnis, den Browser und den Server auf ein zweites Konto. Es hält ein nachlässiges oder getäuschtes Modell auf und die gewöhnliche Injektion, die über das verschlüsselte Verzeichnis laufen. Es hält kein Modell auf, das darauf angelegt ist zu schaden: Dieses läuft unter Ihrem Konto und erreicht Ihre Shell und
sudo. - Leichtsinnig ist der Rechner, den die Installation ergibt, wenn Sie nichts weiter tun: Das Modell und das verschlüsselte Verzeichnis teilen sich ein Konto. Der Kernel schließt nichts; es halten nur Regeln (die Konfiguration des Clients, die Prüfungen des Servers).
Die zehn Wege, die ein Modell zu einem Geheimnis nehmen kann
Ein Weg ist vom Kernel geschlossen, wenn das System verweigert, was das Modell auch versucht, vom Server geschlossen, wenn der Code des Servers es verweigert und das Modell weder diesen Code noch seine Konfiguration ändern kann, und sonst offen. Die Stufe eines Rechners ist die seines offensten Weges.
| Weg | Was ein Modell mit einer Shell versucht | Kompromisslos | Normal | Leichtsinnig (nicht empfohlen) |
|---|---|---|---|---|
| 1. Das verschlüsselte Verzeichnis lesen: Zugangsdaten, Journal, Aufnahmen, Downloads | ls und cat im Einhängepunkt | Kernel | Kernel | offen |
| 2. Das Browserprofil lesen: die Cookies der offenen Sitzungen | das Profilverzeichnis lesen | Kernel | Kernel | offen |
| 3. Den Browser ohne den Server über seinen Debugging-Port steuern | sich mit Port 9222 verbinden | Kernel | Kernel | offen |
| 4. Sich als der Browser ausgeben: vor ihm auf dem Port lauschen, damit der Server sich anbindet und dort ein Passwort tippt | einen Lauscher auf dem Port öffnen, dann status aufrufen | Server | Server | entfällt |
| 5. Ändern, was der Server erlaubt: Bedienerprofil, Unit, Befehl des Servers | das Profil und die Unit schreiben | Kernel | Kernel | offen |
| 6. Seine Spur im Journal löschen oder umschreiben | in das Journalverzeichnis schreiben | Kernel | Kernel | offen |
| 7. An Ihrer Stelle das Bestätigungsfenster beantworten | xdotool, /dev/uinput, der Socket Ihres Bildschirms | Kernel | offen | offen |
8. Den Speicher des Servers, des Browsers oder von gocryptfs lesen | /proc/<pid>/mem, gdb -p | Kernel | Kernel | offen |
| 9. Ein Passwort abgreifen, das Sie tippen | einen Alias in Ihre Shell-Startdateien schreiben, die Tastaturereignisse lesen | Kernel | offen | offen |
| 10. Administrator werden | sudo -n true, sudo -l, Tastenanschläge in Ihr Terminal einspeisen | Kernel | offen | offen |
Die Wege 7, 9 und 10 bleiben auf der normalen Stufe offen, weil das Modell unter dem Konto läuft, dem Ihr Bildschirm, Ihre Startdateien und Ihre sudo-Rechte gehören. Auf der kompromisslosen Stufe verweigert der Bildschirm das Modellkonto, die Startdateien und die Tastaturereignisse sind ihm verschlossen, und es hat kein sudo. Die Wege 7 und 9 und der unten verwendete Befehl xhost hängen vom Anzeigeserver Ihrer Sitzung ab. Sie wurden zweimal gemessen: unter X11, in einer KDE-Sitzung, und unter Wayland, in einer GNOME-Sitzung; der Abschnitt zu einer Wayland-Sitzung weiter unten nennt, was dort anders ist.
Was jede Stufe beibehält
Der Server tut Folgendes auf jeder Stufe, weil sein Code es tut:
- Der Wert eines Zugangsdatums steht nie in einem Werkzeugergebnis, im Journal oder auf einer Befehlszeile;
- ein Zugangsdatum wird nur auf seinem eigenen Ursprung getippt;
- eine Zahlung, eine Löschung oder eine Änderung eines Geheimnisses wartet auf Ihre Bestätigung.
Diese Prüfungen schützen vor einem Leck über die Werkzeuge. Sie schützen nicht vor einem Modell mit einer Shell unter dem Konto des verschlüsselten Verzeichnisses, und deshalb gibt es die Stufen. Eine Stufe schützt den Wert eines Geheimnisses, nicht die Nutzung einer Sitzung, die im eigenen Browser geöffnet ist: Das Modell kann diese Sitzung auf jeder Stufe nutzen, innerhalb der Grenzen der roten Liste (Grenzen, MCP-Client anbinden).
Die eigene Stufe prüfen: der Bericht von isolation
mcp-server-diwall-browser-setup isolation läuft vom Konto des Modells aus. Es probiert jeden der zehn Wege mit dem Versuch der Tabelle oben, schreibt nichts, fragt kein Passwort ab, startet kein sudo und liest keinen Inhalt des Servers. Für jeden Weg sagt es: vom Kernel geschlossen, vom Server geschlossen, offen, entfällt oder von hier aus nicht messbar, danach die erreichte Stufe. Der Unterbefehl kommt mit Version 0.0.2 des Servers.
- Ohne Argument nimmt es
diwall-mcpals Serverkonto, wenn es dieses Konto gibt, sonst Ihr Konto.isolationgefolgt von einem Kontonamen nimmt stattdessen dieses Konto;--port PORTnennt einen anderen Debugging-Port;--jsongibt die Urteile für ein Skript aus. - Ein Weg, der das verschlüsselte Verzeichnis braucht, ist nicht messbar, solange das Verzeichnis nicht eingehängt ist, und Weg 6 ist nicht messbar, bevor der Server einmal gelaufen ist, weil das Journalverzeichnis dann noch nicht existiert: Der Bericht führt einen solchen Weg auf und zählt ihn nicht als geschlossen.
- Weg 4 wird vom installierten Code des Servers an einer simulierten Tabelle versucht, in der das Modellkonto lauscht, nicht an einem echten Lauscher. Weg 10 wird ohne
sudoversucht: Gruppen, lesbaresudoers-Regeln und der Schalter für die Terminal-Injektion. Eine Regel, die nurrootlesen kann, ist vom Modellkonto aus unsichtbar, und der Bericht sagt es.
Zu den Befehlen und ihren Ausgaben
Die Befehle wurden auf zwei Debian-13-Rechnern ausgeführt, eine Stufe nach der anderen, und danach in umgekehrter Reihenfolge rückgängig gemacht: auf einem mit einer KDE-Sitzung unter X11, der die Ausgaben der drei Stufen lieferte, und auf einem mit einer GNOME-48.7-Sitzung unter Wayland, der dieselben Befehle noch einmal ausführte und die Ausgaben des Abschnitts zu einer Wayland-Sitzung lieferte. Die Ausgaben sind aus diesen Läufen kopiert, mit Ersetzungen: Ihr Konto heißt alice, sein Home-Verzeichnis ~, und das Arbeitsverzeichnis des Wayland-Rechners /var/tmp/test. Die Fortschrittszeilen von apt und die erklärenden Absätze, die der Einrichtungsassistent um die Passwortabfragen herum ausgibt, sind weggelassen. Die Systembefehle liefen mit LC_ALL=C, damit ihre Meldungen überall gleich lauten; bei Ihnen folgen sie Ihrer Sprache, und die gezeigten Versionsnummern sind die dessen, was an jenem Tag installiert war. Die Meldungen des Einrichtungsassistenten sind französisch. Die Spurzeilen, die eine Shell für einen in einer Subshell ausgeführten Befehl schreibt ($$), sind in den Wayland-Ausgaben weggelassen.
Alle Befehle verwenden dieselben Beispielwerte: Der Bediener ist das Konto, unter dem Sie angemeldet sind (alice in den Ausgaben, $(id -un) in den Befehlen), das Serverkonto ist diwall-mcp, das Modellkonto ist agent, das verschlüsselte Verzeichnis liegt in /var/lib/diwall-mcp, und der Debugging-Port ist 9222.
use_pty. Debian 13 liefert Defaults use_pty in /etc/sudoers mit: Die Datei des Pakets sudo 1.9.16 hat es in Zeile 15. Beide Rechner hatten es. Der Wayland-Rechner hat eine Regel mehr, für ein anderes Programm, sonst unterscheidet sich nichts von der Datei des Pakets:
$ dpkg-query -W '-f=${Version}\n' sudo
1.9.16p2-3+deb13u2
$ mkdir -p /var/tmp/test/apt-sudo
$ cd /var/tmp/test/apt-sudo
$ apt-get download sudo
0% [Working]
Get:1 http://deb.debian.org/debian trixie/main amd64 sudo amd64 1.9.16p2-3+deb13u2 [2086 kB]
0% [1 sudo 9772 B/2086 kB 0%]
100% [Working]
Fetched 2086 kB in 0s (8236 kB/s)
$ dpkg-deb --fsys-tarfile sudo_1.9.16p2-3+deb13u2_amd64.deb
$ tar -xO ./etc/sudoers
$ grep -n use_pty
15:Defaults use_pty
$ diff /dev/fd/63 /dev/fd/62
6a7
> %alice ALL=(ALL) NOPASSWD:/usr/bin/veracrypt
Eine Stufe einrichten, vom Ausgangsrechner aus
Die Schritte unten folgen der Reihenfolge, in der eine Stufe aufgebaut wird: Jede baut auf der vorigen auf, das Konto agent kann also nicht vor diwall-mcp bestehen und diwall-mcp nicht vor dem Ausgangsrechner. Sie enden bei der kompromisslosen Stufe, der Stufe, die den Titel beantwortet; bleiben Sie bei der normalen nur stehen, wenn Sie hinnehmen, dass das Modell Ihren Bildschirm, Ihre Startdateien und sudo behält.
Der Ausgangsrechner, leichtsinnig (nicht empfohlen)
Was sie schließt: nichts durch den Kernel. Was sie offen lässt: jeden Weg außer Weg 4, der keinen Gegenstand hat, weil das Modell schon alles hält. Kosten: keine.
So steht ein Rechner nach der Installation und dem ersten Start, ohne weiteren Schritt. Ein Modell mit einer Shell unter Ihrem Konto listet das verschlüsselte Verzeichnis auf und liest die Zugangsdaten, das Journal und die Downloads; liest die Cookies Ihrer offenen Sitzungen im Browserprofil; steuert den Browser über seinen Debugging-Port, ohne den Server zu durchlaufen; schreibt das Bedienerprofil und die Unit um, die den Server startet; löscht seine Spur im Journal; beantwortet das Bestätigungsfenster an Ihrer Stelle; liest den Speicher des Servers und des Browsers; greift ein Passwort ab, das Sie tippen, indem es einen Alias in Ihre Shell-Startdateien schreibt; und wird Administrator, wenn Ihr Konto zur Gruppe sudo gehört. Der Bericht am Ende dieser Stufe zeigt neun von zehn Wegen offen. Die Prüfungen des Servers halten weiterhin für das, was über seine Werkzeuge läuft; gegen eine Shell halten sie nicht.
Schritt 1. Installieren Sie das Paket und die Werkzeuge der nächsten Stufen, aus dem Verzeichnis, das die Paketdatei enthält. Der Unterbefehl isolation kommt mit Version 0.0.2: Nehmen Sie dieses Paket oder ein neueres, welche Versionsnummer die Ausgabe unten auch zeigt.
sudo apt install ./mcp-server-diwall-browser_*_all.deb socat nftables x11-xserver-utils chromium
Note, selecting 'mcp-server-diwall-browser' instead of './mcp-server-diwall-browser_0.0.2-1_all.deb'
socat is already the newest version (1.8.0.3-1+deb13u1).
nftables is already the newest version (1.1.3-1).
x11-xserver-utils is already the newest version (7.7+11).
chromium is already the newest version (156.0.8078.73-1~deb13u1).
Installing:
mcp-server-diwall-browser
Summary:
Upgrading: 0, Installing: 1, Removing: 0, Not Upgrading: 0
Download size: 0 B / 318 kB
Space needed: 755 kB / 268 GB available
Continue? [Y/n] y
Setting up mcp-server-diwall-browser (0.0.2-1) ...
mcp-server-diwall-browser installed.
Schritt 2. Legen Sie das verschlüsselte Verzeichnis mit seinem Bedienerprofil an und starten Sie dann den eigenen Browser. create fragt das Passwort zweimal ab, dann noch einmal, um das Volume zu öffnen, und zeigt einmalig einen Hauptschlüssel: Schreiben Sie ihn auf Papier. Es wird Chromium verwendet, weil Google Chrome beim ersten Start auf einem neuen Profil ein Fenster mit Nutzungsbedingungen öffnet und den Debugging-Port geschlossen hält, bis sie angenommen sind.
mcp-server-diwall-browser-setup create --browser chromium
mcp-server-diwall-browser-setup browser
Volume chiffré gocryptfs : ~/Vaults/Main.enc, ouvert sur ~/Vaults/Main.
Choose a password for protecting your files.
Password:
Repeat:
Your master key is:
<master key>
The gocryptfs filesystem has been created successfully.
Password:
Filesystem mounted and ready.
Volume ouvert. Profil écrit : ~/.config/mcp-server-diwall-browser/profile.json.
Navigateur lancé (processus 13553) sur le profil du volume, détaché de ce terminal. Ouvrez-y vous-même vos sessions sur les sites.
Schritt 3. Rufen Sie den Server einmal auf, wie es Ihr Client täte, damit sein Journal existiert. Die Sonde sendet die drei Nachrichten des Protokolls, wartet und behält aus der Antwort von status das verschlüsselte Verzeichnis und den Browser.
{ printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"1"}}}' '{"jsonrpc":"2.0","method":"notifications/initialized"}' '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"status","arguments":{}}}'; sleep 6; } | mcp-server-diwall-browser 2>/dev/null | tail -n 1 | grep -o 'encrypted_directory[^}]*}\|browser\\": {[^}]*}'
encrypted_directory\": {\"state\": \"mounted\"}
browser\": {\"attached\": true, \"product\": \"Chrome\", \"version\": \"156.0.8078.73\"}
Schritt 4. Lesen Sie den Bericht. Neun Wege sind offen und Weg 4 hat keinen Gegenstand, die Stufe ist also leichtsinnig.
mcp-server-diwall-browser-setup isolation
Essai des dix voies depuis le compte « alice » (uid 1002) ; le serveur tourne sous « alice » (uid 1002).
Rien n'est écrit, aucun mot de passe n'est demandé, aucun sudo n'est lancé, aucun contenu du serveur n'est lu.
1. Lire le répertoire chiffré : ouverte
le point de montage ~/Vaults/Main se liste depuis ce compte
2. Lire le profil du navigateur : ouverte
le dossier du profil du navigateur se voit depuis ce compte
3. Piloter le navigateur par son port de débogage : ouverte
la connexion à 127.0.0.1:9222 aboutit
4. Se faire passer pour le navigateur : sans objet
le serveur tourne sous ce compte : le modèle a déjà tout
5. Changer ce que le serveur s'autorise : ouverte
ce compte écrit dans ~/.config/mcp-server-diwall-browser
6. Effacer ou réécrire sa trace dans le journal : ouverte
ce compte écrit dans le dossier du journal
7. Répondre à la fenêtre de confirmation : ouverte
l'écran :0 accepte une connexion de ce compte
8. Lire la mémoire du serveur, du navigateur ou de gocryptfs : ouverte
ce compte ouvre la mémoire du processus 1753 de « alice »
9. Capter un mot de passe que l'opérateur tape : ouverte
ce compte écrit dans ~/.bashrc, que le shell de « alice » lit à chaque ouverture
10. Devenir administrateur : ouverte
ce compte est du groupe « sudo » : il devient administrateur, avec un mot de passe que la voie 9 capte, ou sans lui si une règle l'en dispense
Niveau atteint : inconscient (déconseillé)
Normale Stufe: der Server auf einem zweiten Konto
Was sie durch den Kernel schließt: die Wege 1, 2, 3, 5, 6 und 8. Durch den Server: Weg 4. Was sie offen lässt: die Wege 7, 9 und 10. Kosten: das Konto diwall-mcp, eine systemd-Unit und eine Firewall-Regel; die Downloads und die Aufnahmen liegen im verschlüsselten Verzeichnis von diwall-mcp, das Sie mit sudo -u diwall-mcp lesen (der Einhängepunkt hat kein allow_other, deshalb wird auch root abgewiesen); um eine Datei aus diesem Verzeichnis zu holen, siehe den Absatz nach Schritt 9.
Schritt 1. Schließen Sie das Volume des Ausgangsrechners. close beendet zuerst den Browser.
mcp-server-diwall-browser-setup close
Fermeture du navigateur avant le démontage.
Volume fermé : ~/Vaults/Main.
Schritt 2. Legen Sie das Serverkonto an. Es hat kein Passwort, kein sudo und keine andere Gruppe als seine eigene; adduser nimmt es in users auf, was der zweite Befehl entfernt.
sudo adduser --disabled-password --gecos "" diwall-mcp
sudo gpasswd -d diwall-mcp users
id diwall-mcp
usermod: no changes
Removing user diwall-mcp from group users
uid=1000(diwall-mcp) gid=1000(diwall-mcp) groups=1000(diwall-mcp)
Schritt 3. Legen Sie das verschlüsselte Verzeichnis unter diesem Konto an, außerhalb seines Home-Verzeichnisses, damit die Verweigerung bei Weg 1 vom Einhängepunkt kommt und nicht vom Modus eines Verzeichnisses. Der Assistent fragt das Passwort wie beim Ausgangsrechner ab.
sudo install -d -m 755 -o diwall-mcp -g diwall-mcp /var/lib/diwall-mcp
sudo -iu diwall-mcp mcp-server-diwall-browser-setup create --crypt-dir /var/lib/diwall-mcp/Main.enc --mount-dir /var/lib/diwall-mcp/Main --browser chromium
Volume chiffré gocryptfs : /var/lib/diwall-mcp/Main.enc, ouvert sur /var/lib/diwall-mcp/Main.
Choose a password for protecting your files.
Password:
Repeat:
Your master key is:
<master key>
The gocryptfs filesystem has been created successfully.
Password:
Filesystem mounted and ready.
Volume ouvert. Profil écrit : ~/.config/mcp-server-diwall-browser/profile.json.
Schritt 4. Geben Sie diwall-mcp Zugriff auf Ihren Bildschirm, der bis zum Ende Ihrer Sitzung gilt, und starten Sie dann seinen Browser. Das Fenster öffnet sich auf Ihrem Bildschirm. DISPLAY=:0 ist das Display Ihrer Sitzung: echo $DISPLAY verrät es. Unter einer Wayland-Sitzung öffnet xhost XWayland, den X-Server, den GNOME für Anwendungen startet, die kein Wayland sprechen, und DISPLAY ist das Display von XWayland (:1 auf dem gemessenen Rechner: :0 war der Server des Anmeldebildschirms); der Abschnitt zu einer Wayland-Sitzung weiter unten zeigt die Ausgaben. Dieser Zugriff ist die einzige Stelle, an der die Grenze absichtlich geöffnet wird: Das Konto des Servers kann auf Ihrem Bildschirm tippen, nicht nur die Bestätigungsfenster öffnen. Das ist vertretbar, weil jede Stufe dem Code des Servers vertraut und das Modell als Angreifer behandelt.
xhost +SI:localuser:diwall-mcp
sudo -iu diwall-mcp env DISPLAY=:0 mcp-server-diwall-browser-setup browser
localuser:diwall-mcp being added to access control list
Navigateur lancé (processus 14123) sur le profil du volume, détaché de ce terminal. Ouvrez-y vous-même vos sessions sur les sites.
Schritt 5. Schreiben Sie die Brücke: einen systemd-Socket, den Ihr Konto öffnen darf, und einen Dienst, der pro Verbindung einen Server unter diwall-mcp startet. SocketGroup ist die Gruppe des Kontos, unter dem der Client läuft.
sudo tee /etc/systemd/system/mcp-server-diwall-browser.socket >/dev/null <<EOF
[Unit]
Description=Bridge to the browser MCP server: socket of the model account
[Socket]
ListenStream=/run/mcp-server-diwall-browser/mcp.sock
Accept=yes
SocketUser=root
SocketGroup=$(id -un)
SocketMode=0660
DirectoryMode=0755
[Install]
WantedBy=sockets.target
EOF
sudo tee /etc/systemd/system/mcp-server-diwall-browser@.service >/dev/null <<'EOF'
[Unit]
Description=Browser MCP server, one connection (%i)
[Service]
User=diwall-mcp
WorkingDirectory=~
Environment=DISPLAY=:0
ExecStart=/usr/bin/mcp-server-diwall-browser
StandardInput=socket
StandardOutput=socket
StandardError=journal
NoNewPrivileges=yes
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now mcp-server-diwall-browser.socket
stat -c '%A %U %G %n' /run/mcp-server-diwall-browser/mcp.sock
Created symlink '/etc/systemd/system/sockets.target.wants/mcp-server-diwall-browser.socket' -> '/etc/systemd/system/mcp-server-diwall-browser.socket'.
srw-rw---- root alice /run/mcp-server-diwall-browser/mcp.sock
Schritt 6. Fragen Sie den Server über die Brücke nach seinem status, mit der Sonde des Ausgangsrechners.
{ printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"1"}}}' '{"jsonrpc":"2.0","method":"notifications/initialized"}' '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"status","arguments":{}}}'; sleep 6; } | socat - UNIX-CONNECT:/run/mcp-server-diwall-browser/mcp.sock | tail -n 1 | grep -o 'encrypted_directory[^}]*}\|browser\\": {[^}]*}'
encrypted_directory\": {\"state\": \"mounted\"}
browser\": {\"attached\": true, \"product\": \"Chrome\", \"version\": \"156.0.8078.73\"}
Schritt 7. Schließen Sie den Debugging-Port für jedes Konto außer diwall-mcp. Die Abweisung admin-prohibited lässt eine Verbindung sofort mit No route to host scheitern, ein Fehler, den ein geschlossener Port nie ergibt; so lässt sich die Regel von einem Browser unterscheiden, der nicht läuft. Der Port ist das browser.debug_port des Profils. nftables.service lädt die Regel bei jedem Start.
sudo install -d /etc/nftables.d
sudo tee /etc/nftables.d/diwall-mcp.nft >/dev/null <<'EOF'
table inet diwall_mcp {
chain output {
type filter hook output priority 0; policy accept;
oifname "lo" tcp dport 9222 meta skuid != "diwall-mcp" reject with icmpx type admin-prohibited
}
}
EOF
echo 'include "/etc/nftables.d/diwall-mcp.nft"' | sudo tee -a /etc/nftables.conf
sudo nft -c -f /etc/nftables.conf
sudo systemctl reload nftables
systemctl is-enabled nftables
include "/etc/nftables.d/diwall-mcp.nft"
enabled
Auf einem Rechner, auf dem nftables.service deaktiviert ist (systemctl is-enabled nftables antwortet disabled), scheitert reload mit nftables.service is not active, cannot reload, und die Regel wird nicht geladen. Starten Sie den Dienst nicht, bevor Sie /etc/nftables.conf gelesen haben: Seine eigenen Regeln gelten, sobald er startet, und die Datei des gemessenen Rechners weist eingehende Verbindungen standardmäßig ab und hat keine Regel für den SSH-Port. Laden Sie stattdessen die Tabelle allein; sie gilt bis zum nächsten Start:
$ systemctl is-active nftables
inactive
$ sudo nft -f /etc/nftables.d/diwall-mcp.nft
$ sudo nft list ruleset
table inet diwall_mcp {
chain output {
type filter hook output priority filter; policy accept;
oifname "lo" tcp dport 9222 meta skuid != 1001 reject with icmpx admin-prohibited
}
}
$ systemctl is-active nftables
inactive
Schritt 8. Probieren Sie drei Wege von Hand aus Ihrem Konto aus (dem Modellkonto auf dieser Stufe). Weg 3 wird von der Regel abgewiesen, und diwall-mcp verbindet sich trotzdem; Weg 1 wird vom Einhängepunkt abgewiesen; Weg 10 hängt von Ihren sudo-Regeln ab.
bash -c 'exec 3<>/dev/tcp/127.0.0.1/9222'
sudo -u diwall-mcp bash -c 'exec 3<>/dev/tcp/127.0.0.1/9222' && echo "diwall-mcp connects"
ls /var/lib/diwall-mcp/Main
sudo -n true && echo "sudo without a password: yes"
bash: connect: No route to host
bash: line 1: /dev/tcp/127.0.0.1/9222: No route to host
diwall-mcp connects
ls: cannot access '/var/lib/diwall-mcp/Main': Permission denied
sudo without a password: yes
Die Zeile sudo without a password: yes hat die Sonde auf dem gemessenen Konto gefunden, sie ist keine Einstellung, die Sie erreichen sollen. Erscheint diese Zeile nicht, ist Weg 10 deshalb nicht geschlossen: Ein sudo, das ein Passwort verlangt, bleibt offen, solange Weg 9 das Passwort abgreifen kann, das Sie tippen. Die Zeile schreibt das echo des Befehls, wenn sudo -n true gelingt, was eine NOPASSWD-Regel voraussetzt: Auf einem Konto ohne sie antwortet sudo mit sudo: a password is required, die Zeile wird nicht geschrieben und der Exitcode ist 1 (Ausgaben im Abschnitt zu einer Wayland-Sitzung).
Schritt 9. Lesen Sie den Bericht aus Ihrem Konto.
mcp-server-diwall-browser-setup isolation
Essai des dix voies depuis le compte « alice » (uid 1002) ; le serveur tourne sous « diwall-mcp » (uid 1000).
Rien n'est écrit, aucun mot de passe n'est demandé, aucun sudo n'est lancé, aucun contenu du serveur n'est lu.
1. Lire le répertoire chiffré : fermée par le noyau
le noyau refuse ce compte au point de montage (/var/lib/diwall-mcp/Main) : le montage n'a pas d'accès pour un autre compte
2. Lire le profil du navigateur : fermée par le noyau
le noyau refuse ce compte au dossier du profil, qui est dans le volume
3. Piloter le navigateur par son port de débogage : fermée par le noyau
le noyau écarte la connexion au port 9222 (règle de pare-feu par compte)
4. Se faire passer pour le navigateur : fermée par le serveur
le serveur installé refuse un port tenu par un autre compte (debug_endpoint_other_account)
5. Changer ce que le serveur s'autorise : fermée par le noyau
le profil de l'opérateur, l'unité du service et le code du serveur ne s'écrivent pas depuis ce compte
6. Effacer ou réécrire sa trace dans le journal : fermée par le noyau
le noyau refuse ce compte au dossier du journal, qui est dans le volume
7. Répondre à la fenêtre de confirmation : ouverte
l'écran :0 accepte une connexion de ce compte
8. Lire la mémoire du serveur, du navigateur ou de gocryptfs : fermée par le noyau
le noyau refuse ce compte à la mémoire des 13 processus essayés de « diwall-mcp »
9. Capter un mot de passe que l'opérateur tape : ouverte
ce compte écrit dans ~/.bashrc, que le shell de « alice » lit à chaque ouverture
10. Devenir administrateur : ouverte
ce compte est du groupe « sudo » : il devient administrateur, avec un mot de passe que la voie 9 capte, ou sans lui si une règle l'en dispense
Niveau atteint : normal
Eine Datei aus dem verschlüsselten Verzeichnis holen. cp, als sudo -u diwall-mcp ausgeführt, wird abgewiesen, wenn der Zielordner Ihnen gehört, weil diwall-mcp dort nicht schreiben kann. Entweder schreibt Ihr eigenes Konto die Datei, indem es sie als diwall-mcp liest und die Ausgabe umleitet, oder die Kopie geht in einen Ordner, in den jeder schreiben darf, und gehört dann diwall-mcp:
$ mkdir -p /var/tmp/test/recu
$ sudo -n -u diwall-mcp sh -c 'mkdir -p /var/lib/diwall-mcp/Main/downloads && echo "contenu d essai" > /var/lib/diwall-mcp/Main/downloads/essai.txt'
$ sudo -u diwall-mcp cp /var/lib/diwall-mcp/Main/downloads/essai.txt /var/tmp/test/recu/
cp: cannot create regular file '/var/tmp/test/recu/essai.txt': Permission denied
$ sudo -u diwall-mcp cat /var/lib/diwall-mcp/Main/downloads/essai.txt
$ ls -l /var/tmp/test/recu/
total 4
-rw-rw-r-- 1 alice alice 16 Nov 1 00:49 essai.txt
$ cat /var/tmp/test/recu/essai.txt
contenu d essai
$ rm /var/tmp/test/recu/essai.txt
$ chmod 1777 /var/tmp/test/recu
$ sudo -u diwall-mcp cp /var/lib/diwall-mcp/Main/downloads/essai.txt /var/tmp/test/recu/
$ ls -l /var/tmp/test/recu/
total 4
-rw-rw-r-- 1 diwall-mcp diwall-mcp 16 Nov 1 00:49 essai.txt
Unter einer Wayland-Sitzung (GNOME)
Die obigen Befehle wurden unter X11 ausgeführt und dann noch einmal in einer GNOME-Sitzung unter Wayland (Debian 13, GNOME Shell 48.7), in der dieselben zehn Wege versucht wurden. Die Ausgaben dieses Abschnitts stammen von diesem zweiten Rechner.
Die Sitzung. Fragen Sie Ihre Sitzung, welche es ist und wo XWayland liegt:
$ systemctl --user show-environment
$ grep -E '^(DISPLAY|WAYLAND_DISPLAY|XDG_SESSION_TYPE)='
DISPLAY=:1
WAYLAND_DISPLAY=wayland-0
XDG_SESSION_TYPE=wayland
$ ls -ld /run/user/1000 /run/user/1000/wayland-0
drwx------ 15 alice alice 580 Nov 1 00:15 /run/user/1000
srwxrwxr-x 1 alice alice 0 Nov 1 00:14 /run/user/1000/wayland-0
$ ls -l /tmp/.X11-unix
total 0
srwxrwxrwx 1 root root 0 Nov 1 00:08 X0
srwxrwxr-x 1 alice alice 0 Nov 1 00:14 X1
srwxrwxr-x 1 alice alice 0 Nov 1 00:14 X2
$ gnome-shell --version
GNOME Shell 48.7
Das Verzeichnis Ihrer Sitzung ist für die anderen Konten gesperrt (drwx------), und der Wayland-Socket liegt darin: Eine Anwendung eines anderen Kontos erreicht ihn nicht. Sie erreicht Ihren Bildschirm nur über XWayland, das xhost öffnet.
Was xhost ändert. Die Befehle sind dieselben; der Zugriff läuft über XWayland. Ein Fenster von diwall-mcp, das mit dem DISPLAY von XWayland geöffnet wird, existiert für Ihren Bildschirm; mit dem alleinigen WAYLAND_DISPLAY öffnet es sich gar nicht:
$ sleep 3
$ sudo -n -u diwall-mcp env DISPLAY=:1 zenity --info --title essai-b-x11 --text 'essai b' --timeout 8
MESA: error: Failed to attach to x11 shm
MESA: error: Failed to attach to x11 shm
$ xdotool search --name essai-b-x11
33554436
$ ps -o user=,comm= -p 15904
diwall-+ zenity
$ wait
$ sudo -n -u diwall-mcp ls /run/user/1000/wayland-0
ls: cannot access '/run/user/1000/wayland-0': Permission denied
$ sudo -n -u diwall-mcp env -u DISPLAY -u XAUTHORITY WAYLAND_DISPLAY=wayland-0 XDG_RUNTIME_DIR=/run/user/1000 GDK_BACKEND=wayland zenity --info --text 'essai b' --timeout 8
(zenity:16088): Gtk-WARNING **: 00:49:10.708: Failed to open display
Zwei Einzelheiten ergaben sich aus diesen Versuchen. Die Standarddarstellung von zenity (GTK 4) unter einem anderen Konto erzeugt das Fenster, lässt es aber unsichtbar (MESA: error: Failed to attach to x11 shm); ab Version 0.0.2 startet der Server zenity mit GSK_RENDERER=cairo und bevorzugt kdialog, wenn es installiert ist. Und sudo behält DISPLAY und XAUTHORITY Ihres Kontos, sofern nichts anderes gesagt wird: Entfernen Sie sie, um Wayland allein zu versuchen, wie oben.
Weg 7. Auf der normalen Stufe beantwortet Ihr Konto das Bestätigungsfenster von diwall-mcp: Das Fenster wird unter diwall-mcp so geöffnet, wie der Server es öffnet, dann fokussiert und mit xdotool von Ihrem Konto aus beantwortet, und das Programm erhält grant.
$ sleep 3
$ sudo -n -u diwall-mcp env DISPLAY=:1 kdialog --title essai-reponse --radiolist 'Autoriser ?' refuse Refuser on grant Autoriser off
Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
If this causes problems, reconfigure your locale. See the locale(1) manual
for more information.
$ xdotool search --name essai-reponse
16777252
33554439
$ xdotool windowfocus 33554439
$ xdotool key Down
$ xdotool key Return
$ wait
$ cat /var/tmp/test/reponse.txt
grant
$ ls -l /dev/uinput
crw------- 1 root root 10, 223 Nov 1 00:47 /dev/uinput
Auf der kompromisslosen Stufe erreicht agent weder den Wayland-Socket noch die Socket-Datei von XWayland (Permission denied) und kann weder xdotool noch /dev/uinput benutzen. Der abstrakte Socket von XWayland nimmt die Verbindung an, also ist es die Autorisierung von XWayland, die agent abweist: Ohne lesbaren Cookie und ohne xhost-Regel kommt nichts durch. Eine für agent geöffnete Regel öffnet den Bildschirm, und der Bericht sagt es:
$ sudo -iu agent xdotool getmouselocation
Authorization required, but no authorization protocol specified
Error: Can't open display: (null)
Failed creating new xdo instance
$ sudo -iu agent test -w /dev/uinput
$ sudo -iu agent head -c 1 /dev/input/event0
head: cannot open '/dev/input/event0' for reading: Permission denied
$ sudo -iu agent test -w ~/.bashrc
$ xhost +SI:localuser:agent
localuser:agent being added to access control list
$ sudo -iu agent mcp-server-diwall-browser-setup isolation
Essai des dix voies depuis le compte « agent » (uid 1002) ; le serveur tourne sous « diwall-mcp » (uid 1001).
Rien n'est écrit, aucun mot de passe n'est demandé, aucun sudo n'est lancé, aucun contenu du serveur n'est lu.
1. Lire le répertoire chiffré : fermée par le noyau
le noyau refuse ce compte au point de montage (/var/lib/diwall-mcp/Main) : le montage n'a pas d'accès pour un autre compte
2. Lire le profil du navigateur : fermée par le noyau
le noyau refuse ce compte au dossier du profil, qui est dans le volume
3. Piloter le navigateur par son port de débogage : fermée par le noyau
le noyau écarte la connexion au port 9222 (règle de pare-feu par compte)
4. Se faire passer pour le navigateur : fermée par le serveur
le serveur installé refuse un port tenu par un autre compte (debug_endpoint_other_account)
5. Changer ce que le serveur s'autorise : fermée par le noyau
le profil de l'opérateur, l'unité du service et le code du serveur ne s'écrivent pas depuis ce compte
6. Effacer ou réécrire sa trace dans le journal : fermée par le noyau
le noyau refuse ce compte au dossier du journal, qui est dans le volume
7. Répondre à la fenêtre de confirmation : ouverte
l'écran :1 accepte une connexion de ce compte par son socket abstrait
8. Lire la mémoire du serveur, du navigateur ou de gocryptfs : fermée par le noyau
le noyau refuse ce compte à la mémoire des 27 processus essayés de « diwall-mcp »
9. Capter un mot de passe que l'opérateur tape : fermée par le noyau
les fichiers de démarrage de « alice » et les événements du clavier sont fermés à ce compte
10. Devenir administrateur : fermée par le noyau
aucun groupe d'administration, aucune règle lisible à son nom, injection dans le terminal refusée ; une règle que seul root lit n'est pas visible d'ici
Niveau atteint : normal
$ sudo -iu agent xdotool getmouselocation
x:1010 y:368 screen:0 window:4194313
$ xhost -SI:localuser:agent
localuser:agent being removed from access control list
Wege 9 und 10. Dieselben Versuche wie unter X11 geben dieselben Ergebnisse. Ihr Konto schreibt in seine Startdateien und liest die Tastaturereignisse nicht; use_pty ist vorhanden, legacy_tiocsti ist 0, und Ihre sudo-Regel lässt die Sonde ihre Zeile schreiben:
$ ls -l /dev/input/event0
crw-rw---- 1 root input 13, 64 Nov 1 00:47 /dev/input/event0
$ head -c 1 /dev/input/event0
head: cannot open '/dev/input/event0' for reading: Permission denied
$ test -w ~/.bashrc
$ echo writable
writable
$ sudo -n grep -rn use_pty /etc/sudoers /etc/sudoers.d/
/etc/sudoers:15:Defaults use_pty
/etc/sudoers.d/kdesu-sudoers:4:Defaults!/usr/lib/*/libexec/kf5/kdesu_stub !use_pty
$ cat /proc/sys/dev/tty/legacy_tiocsti
0
$ sudo -n true
$ echo 'sudo without a password: yes'
sudo without a password: yes
$ sudo -n -u diwall-mcp sudo -n true
sudo: a password is required
Von agent aus ist das Terminal ein anderes als Ihres, was use_pty bewirkt, und sudo verlangt ein Passwort:
$ sudo -iu agent tty
/dev/pts/1
$ tty
/dev/pts/0
$ sudo -iu agent sudo -n true
sudo: a password is required
Kompromisslose Stufe: das Modell auf einem dritten Konto
Was sie schließt: jeden der zehn Wege, durch den Kernel außer Weg 4, den der Server schließt. Was sie offen lässt: nichts. Kosten: das Konto agent; der Client wird mit sudo -iu agent aus Ihrem Terminal gestartet, und use_pty von sudo hindert den Client daran, Tastenanschläge in dieses Terminal einzuspeisen. Debian 13 liefert Defaults use_pty in /etc/sudoers mit, und beide gemessenen Rechner hatten es; prüfen Sie auf einem anderen System, ob diese Zeile vorhanden ist, sonst wird die Einspeisung nicht verweigert.
Schritt 1. Legen Sie das Modellkonto an, auf dieselbe Weise wie diwall-mcp.
sudo adduser --disabled-password --gecos "" agent
sudo gpasswd -d agent users
id agent
usermod: no changes
Removing user agent from group users
uid=1001(agent) gid=1001(agent) groups=1001(agent)
Schritt 2. Übergeben Sie den Socket an die Gruppe von agent. Eine ergänzende Datei fügt die Änderung hinzu, sodass ihr Rückgängigmachen eine einzige Datei entfernt und die Unit der normalen Stufe so lässt, wie sie war.
sudo install -d /etc/systemd/system/mcp-server-diwall-browser.socket.d
printf '[Socket]\nSocketGroup=agent\n' | sudo tee /etc/systemd/system/mcp-server-diwall-browser.socket.d/uncompromising.conf
sudo systemctl daemon-reload
sudo systemctl restart mcp-server-diwall-browser.socket
stat -c '%A %U %G %n' /run/mcp-server-diwall-browser/mcp.sock
[Socket]
SocketGroup=agent
srw-rw---- root agent /run/mcp-server-diwall-browser/mcp.sock
Schritt 3. Ihr eigenes Konto öffnet die Brücke nicht mehr; agent öffnet sie.
socat - UNIX-CONNECT:/run/mcp-server-diwall-browser/mcp.sock < /dev/null 2>&1 | sed 's/^.*socat\[[0-9]*\] //'
{ printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"1"}}}' '{"jsonrpc":"2.0","method":"notifications/initialized"}' '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"status","arguments":{}}}'; sleep 6; } | sudo -u agent socat - UNIX-CONNECT:/run/mcp-server-diwall-browser/mcp.sock | tail -n 1 | grep -o 'encrypted_directory[^}]*}\|browser\\": {[^}]*}'
E connect(, AF=1 "/run/mcp-server-diwall-browser/mcp.sock", 41): Permission denied
encrypted_directory\": {\"state\": \"mounted\"}
browser\": {\"attached\": true, \"product\": \"Chrome\", \"version\": \"156.0.8078.73\"}
Schritt 4. Tragen Sie die Brücke als Befehl Ihres MCP-Clients ein, der unter agent läuft. In der Erklärung des Bedienerhandbuchs, Abschnitt 2.1, ist der command die Zeile unten, und es gibt keinen Block environment: Das Profil, der Bildschirm und das Arbeitsverzeichnis sind durch die Unit festgelegt.
{
"command": ["socat", "STDIO", "UNIX-CONNECT:/run/mcp-server-diwall-browser/mcp.sock"]
}
Schritt 5. Probieren Sie dieselben drei Wege aus agent aus und lesen Sie dann den Bericht aus agent.
sudo -iu agent bash -c 'exec 3<>/dev/tcp/127.0.0.1/9222'
sudo -iu agent ls /var/lib/diwall-mcp/Main
sudo -iu agent sudo -n true
sudo -iu agent mcp-server-diwall-browser-setup isolation
bash: connect: No route to host
bash: line 1: /dev/tcp/127.0.0.1/9222: No route to host
ls: cannot access '/var/lib/diwall-mcp/Main': Permission denied
sudo: a password is required
Essai des dix voies depuis le compte « agent » (uid 1001) ; le serveur tourne sous « diwall-mcp » (uid 1000).
Rien n'est écrit, aucun mot de passe n'est demandé, aucun sudo n'est lancé, aucun contenu du serveur n'est lu.
1. Lire le répertoire chiffré : fermée par le noyau
le noyau refuse ce compte au point de montage (/var/lib/diwall-mcp/Main) : le montage n'a pas d'accès pour un autre compte
2. Lire le profil du navigateur : fermée par le noyau
le noyau refuse ce compte au dossier du profil, qui est dans le volume
3. Piloter le navigateur par son port de débogage : fermée par le noyau
le noyau écarte la connexion au port 9222 (règle de pare-feu par compte)
4. Se faire passer pour le navigateur : fermée par le serveur
le serveur installé refuse un port tenu par un autre compte (debug_endpoint_other_account)
5. Changer ce que le serveur s'autorise : fermée par le noyau
le profil de l'opérateur, l'unité du service et le code du serveur ne s'écrivent pas depuis ce compte
6. Effacer ou réécrire sa trace dans le journal : fermée par le noyau
le noyau refuse ce compte au dossier du journal, qui est dans le volume
7. Répondre à la fenêtre de confirmation : fermée par le noyau
l'écran refuse ce compte (sans cookie lisible), et /dev/uinput lui est fermé (1 écran(s) essayé(s))
8. Lire la mémoire du serveur, du navigateur ou de gocryptfs : fermée par le noyau
le noyau refuse ce compte à la mémoire des 13 processus essayés de « diwall-mcp »
9. Capter un mot de passe que l'opérateur tape : fermée par le noyau
les fichiers de démarrage de « alice » et les événements du clavier sont fermés à ce compte
10. Devenir administrateur : fermée par le noyau
aucun groupe d'administration, aucune règle lisible à son nom, injection dans le terminal refusée ; une règle que seul root lit n'est pas visible d'ici
Niveau atteint : intransigeant
Zu einer weniger strengen Stufe zurückgehen
Machen Sie alles in umgekehrter Reihenfolge rückgängig. Die Befehle entfernen die Konten und die Units; das verschlüsselte Verzeichnis von diwall-mcp hält Ihre Browsersitzungen, und der letzte Befehl des zweiten Schritts löscht es mit ihnen: Kopieren Sie vorher, was Sie brauchen.
Von kompromisslos zu normal. Entfernen Sie die ergänzende Datei, dann das Modellkonto samt Home-Verzeichnis. Ihr eigenes Konto öffnet die Brücke wieder.
sudo rm /etc/systemd/system/mcp-server-diwall-browser.socket.d/uncompromising.conf
sudo rmdir /etc/systemd/system/mcp-server-diwall-browser.socket.d
sudo systemctl daemon-reload
sudo systemctl restart mcp-server-diwall-browser.socket
sudo deluser --remove-home agent
Von normal zu leichtsinnig. Nehmen Sie den Zugriff auf Ihren Bildschirm zurück, schließen Sie das Volume und den Browser von diwall-mcp, entfernen Sie die Brücke, die Firewall-Regel und das Konto, dann das verschlüsselte Verzeichnis.
xhost -SI:localuser:diwall-mcp
sudo -iu diwall-mcp mcp-server-diwall-browser-setup close
sudo systemctl disable --now mcp-server-diwall-browser.socket
sudo rm /etc/systemd/system/mcp-server-diwall-browser.socket /etc/systemd/system/mcp-server-diwall-browser@.service
sudo systemctl daemon-reload
sudo rm /etc/nftables.d/diwall-mcp.nft
sudo rmdir /etc/nftables.d
sudo sed -i '\|^include "/etc/nftables.d/diwall-mcp.nft"$|d' /etc/nftables.conf
sudo systemctl reload nftables
sudo deluser --remove-home diwall-mcp
sudo rm -r /var/lib/diwall-mcp
localuser:diwall-mcp being removed from access control list
Fermeture du navigateur avant le démontage.
Volume fermé : /var/lib/diwall-mcp/Main.
Removed '/etc/systemd/system/sockets.target.wants/mcp-server-diwall-browser.socket'.
Wenn unter diwall-mcp ein Bestätigungsfenster gelaufen ist, kann der letzte Befehl mit userdel: user diwall-mcp is currently used by process … scheitern: Das Fenster hat einen Sitzungsbus zurückgelassen. Beenden Sie die Prozesse des Kontos, warten Sie einige Sekunden, entfernen Sie das Konto erneut und räumen Sie dann auf, was bleibt: die Socket-Datei in /run (die Unit ist weg, die Datei wird nicht mit ihr entfernt) und, auf einem Rechner, auf dem nftables.service deaktiviert ist, die von Hand geladene Tabelle, die reload nicht entlädt:
$ ps -u diwall-mcp -o pid,comm
PID COMMAND
15910 dbus-launch
15911 dbus-daemon
15949 xdg-desktop-por
15955 xdg-permission-
15961 xdg-document-po
15972 xdg-desktop-por
15977 gvfsd
15983 gvfsd-fuse
15999 at-spi-bus-laun
16005 dbus-daemon
16011 at-spi2-registr
$ sudo pkill -u diwall-mcp
$ sleep 5
$ ps -u diwall-mcp -o pid,comm
PID COMMAND
$ sudo deluser --remove-home diwall-mcp
$ ls -la /run/mcp-server-diwall-browser
total 0
drwxr-xr-x 2 root root 60 Nov 1 00:49 .
drwxr-xr-x 40 root root 960 Nov 1 00:49 ..
srw-rw---- 1 root alice 0 Nov 1 00:49 mcp.sock
$ sudo nft list ruleset
table inet diwall_mcp {
chain output {
type filter hook output priority filter; policy accept;
oifname "lo" tcp dport 9222 meta skuid != 1001 reject with icmpx admin-prohibited
}
}
$ sudo nft delete table inet diwall_mcp
$ sudo rm -r /run/mcp-server-diwall-browser
Von leichtsinnig zu nichts. Schließen Sie Ihr Volume und entfernen Sie das Paket. Ihr verschlüsseltes Verzeichnis bleibt dort, wo create es angelegt hat; löschen Sie es selbst, wenn Sie es nicht brauchen.
mcp-server-diwall-browser-setup close
sudo apt purge mcp-server-diwall-browser
Le volume est déjà fermé.
REMOVING:
mcp-server-diwall-browser*
Summary:
Upgrading: 0, Installing: 0, Removing: 1, Not Upgrading: 0
Freed space: 755 kB
Continue? [Y/n] y
Removing mcp-server-diwall-browser (0.0.2-1) ...
mcp-server-diwall-browser removed. Your operator profile and your encrypted directory were not touched.
Purging configuration files for mcp-server-diwall-browser (0.0.2-1) ...
mcp-server-diwall-browser removed. Your operator profile and your encrypted directory were not touched.
Was keine Stufe verspricht
- Einen Fehler des Kernels oder des Servers.
- Ein Geheimnis, das Sie in eine Unterhaltung einfügen.
- Die Nutzung einer Sitzung, die im eigenen Browser geöffnet ist: Das Modell kann darin handeln, innerhalb der Grenzen der roten Liste, auf jeder Stufe.
- Was der Anbieter des Modells von den Seiten erhält, die das Modell liest. Ein lokales Modell beseitigt diese Preisgabe; eine Injektion beseitigt es nicht.
Eine Stufe wird zu einem bestimmten Zeitpunkt gemessen: Eine Gruppe, die einem Konto hinzugefügt wird, eine sudoers-Regel oder eine Änderung an xhost senkt sie. Führen Sie mcp-server-diwall-browser-setup isolation nach jeder Änderung des Rechners erneut aus.