KI-Agenten unter separatem Linux-Benutzerkonto betreiben (am Beispiel von Claude)
Motivation
KI Agenten sind gerade bei der Softwareentwicklung viel effizienter, als das Copy&Paste-in-und-aus-dem-Webbrowser-Verfahren. Wenn man jedoch mit KI Agenten arbeitet, räumt man diesen Rechte wie Verzeichnis-/Dateizugriff und das Ausführen von Programmen und existierenden oder selbst generierten Scripten ein. Dies birgt erhebliche Sicherheitsrisiken:
-
Muss man dem Hersteller der KI vertrauen (und der dahinterstehenden Regierung und den dortigen Geheimdiensten), dass auf den KI-Server hochgeladenen Dateien wirklich vertraulich behandelt werden. Da der KI-Agent Zugriff auf das Dateisystem hat, und zwar auf alle Dateien, die der ausführende Nutzer selber auch lesen kann (unabhängig mal von der Freigabe bestimmter Verzeichnisse für die KI), kann der KI Agent wirklich jede Datei lesen und die Daten zur Verarbeitung in der KI-Engine hochladen. Werden die Daten weiter gegeben, oder in veränderter Form in Umlauf gebracht oder gar kommerzialisiert, ist es nahezu aussichtslos den Beweis zu erbringen, dass die KI-Software die Daten geleakt hat.
Auch kann die KI ohne großen Aufwand einen Quelltext abwandeln, mit eigenen Lizenzbedingungen versehen und so umstrukturieren, dass der Originalquelltext nur noch ansatzweise zu erkennen ist. Sollte ein solcher veränderter Quelltext von einer Firma vermarktet werden, ist man möglicherweise selbst später in der Zwangslage nachzuweisen, dass man selbst der Autor der IP ist und nicht den Code der Firma via KI verändert hat. Dies wird ohne lückenlose Aufzeichnung der Entwicklungshistorie sehr schwierig sein (deshalb ist ein git-Repo Pflicht).
Ganz besonders kritisch ist das unkontrollierte hochladen von Daten dann, wenn die KI Zugang im Dateisystem zu geschützten Persönlichkeitsdaten hat (Verträge, Gehaltsabrechnungen etc.). -
Beim Ausführen selbst erstellter Skripte kann die KI via cd-Befehl die aktuelle Verzeichnisstruktur verlassen und im Worst-Case durch Fehler (z.B. in einem selbstgenerierten Skript) Dateien löschen/ändern und so zu Datenverlust führen.
Aus all diesen Gründen folgt zwingend, dass man der KI nur auf die Daten Zugriff geben darf, welche für die Arbeit benötigt werden. Und der Zugriff auf die anderen Daten sollte durch Schutzmechanismen des Betriebssystems gewährleistet werden. Wie man das am besten macht, ohne die Bequemlichkeit des Arbeitens einzuschränken, wird nachfolgend erklärt.
Grundlegendes zur Arbeit mit KI-Agenten
KI-Agenten können und sollten Dateien im Dateisystem direkt manipulieren. Um diese Änderungen zu verfolgen, sollte man ausschließlich mit Versionskontrollsystemen arbeiten. Selbst bei lokalen Testprojekten sollte man immer ein git-Repository initialisieren, um so die einzelnen Bearbeitungsschritte der KI prüfen und nachvollziehen zu können. Auf diese Weise kann man auch ungewollte Änderungen leicht rückgängig machen.
1
2
# Initialisierung des aktuellen Verzeichnisses als git-repo
$ git init .
Konzept zur abgeschirmten Arbeit von KI-Agenten
Die Grundidee ist die, dass es zwei Nutzerkonten gibt: einmal das eigene Nutzerkonto (nachfolgend wird der Benutzername deinuser angenommen), und einmal ein Konto für die Arbeit mit der KI (nachfolgend als Nutzer claudette bezeichnet).
Im eigenen Konto arbeitet man klassisch mit der grafischen Oberflächen und GUI Tools. Wenn man die KI braucht, öffnet man ein Terminal, wechselt zum KI-Nutzerkonto und arbeitet dann in der Konsole im gemeinsamen Arbeitsverzeichnis.
Beide Nutzer – der eigene Account und der KI-Nutzer – gehören einer gemeinsamen Gruppe an. Alle geteilten Dateien und Verzeichnisse gehören dieser Gruppe, mit Gruppenrechten für Lesen und Schreiben.
1
2
3
deinuser (eigenes Konto) ──┐
├── gemeinsame Gruppe: kiworker
claudette (KI-Nutzer) ──┘
Nutzer und Gruppe anlegen
Das Anlegen von Nutzern kann man auch mit der GNOME-Nutzerverwaltung erledigen. In der Kommandozeile geht es schneller:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# KI-Nutzer anlegen (mit eigenem Home-Verzeichnis für ~/.claude Konfiguration)
deinuser@box:~$ sudo useradd --create-home --shell /bin/bash \
--comment "Meine KI-Agentin" claudette
# Passwort festlegen
deinuser@box:~$ sudo passwd claudette
# Gemeinsame Gruppe 'kiworker' anlegen
deinuser@box:~$ sudo groupadd kiworker
# Eigenen Account zur Gruppe hinzufügen
deinuser@box:~$ sudo usermod -aG kiworker deinuser
# KI-Nutzer ebenfalls zur Gruppe hinzufügen
deinuser@box:~$ sudo usermod -aG kiworker claudette
Man kann die Gruppenzuordnung auch durch Bearbeiten der Datei
/etc/grouperledigen, falls man sich die obigen Befehle nicht merken kann.
Jetzt sollte man sich neu einloggen bzw. neu booten, damit die Gruppenzuordnung neu gelesen wird. Nach dem Einloggen mit
1
deinuser@box:~$ groups
prüfen, ob man wirklich in der Gruppe kiworker ist.
git-Config für den KI Nutzer
Wenn man den KI-Agenten selbst auch commits machen lassen will, sollte man die git-Einstellungen für den Nutzer claudette setzen:
1
2
3
4
5
6
7
# als eigener Nutzer eingeloggt, zum Benutzer claudette wechseln
deinuser@box:~$ su - claudette
# hier sollte man seine eigenen E-Mail und Nutzername setzen, sofern man
# zwischen KI-Agenten-Commits und eigenen Commits nicht unterscheiden will/muss
claudette@box:~$ git config --global user.email "meine@email.com"
claudette@box:~$ git config --global user.name "Mein Name"
Gemeinsames Arbeitsverzeichnis anlegen
Die gemeinsame Arbeit wird auch in einer gemeinsamen Dateisystemstruktur gemacht. Das könnte ein Verzeichnis unterhalb des Home-Verzeichnisses des KI-Nutzers sein, aber besser ist es, ein komplett separates Verzeichnis dafür anzulegen.
Eingeloggt als eigener Nutzer (mit sudo-Rechten):
1
2
3
4
5
6
7
8
9
10
11
12
# gemeinsames Verzeichnis anlegen
deinuser@box:~$ sudo mkdir -p /home/kiworker
# Eigentümer: claudette, Gruppe: kiworker
deinuser@box:~$ sudo chown claudette:kiworker /home/kiworker
# Rechte:
# rwx für Eigentümer (claudette)
# rwx für Gruppe (kiworker) → beide Nutzer lesen & schreiben
# --- für andere
# SetGID-Bit (2): neue Dateien erben automatisch die Gruppe kiworker
deinuser@box:~$ sudo chmod 2775 /home/kiworker
Das SetGID-Bit bewirkt, dass alle im /home/kiworker-Verzeichnis neu erstellten Dateien/Verzeichnisse die gleiche Gruppe kiworker zugewiesen bekommen. Und gleichermaßen alle Dateien/Verzeichnisse in weiteren Unterverzeichnissen. Deshalb nennt man das auch sticky-Bit.
Wenn man Dateien und Verzeichnisse nach /home/kiworker kopiert, werden die Sticky-Bits aber nicht gesetzt. Deshalb muss man diese Sticky-Bits dann nachträglich setzen, siehe Bestehende Verzeichnisse ins gemeinsame Verzeichnis kopieren und Rechte/Eigentümer anpassen.
umask konfigurieren
Die umask bestimmt die Standardrechte neu erstellter Dateien.
Damit Gruppen-Schreibrechte erhalten bleiben, muss die umask für beide Nutzer auf 002 gesetzt werden (statt dem Standard 022).
Für den eigenen Nutzer (~/.bashrc oder ~/.profile)
Entweder man bearbeitet die Konfigurationsdatei mit dem Texteditor, oder via Shell:
1
2
3
4
# eingeloggt und im Homeverzeichnis
deinuser@box:~$ echo 'umask 002' >> .profile
# bzw. in Fedora
deinuser@box:~$ echo 'umask 002' >> .bash_profile
Alternativ kann das auch in .bashrc rein, aber dann wirkt sich das nur auf in der Shell erstellte Dateien/Verzeichnisse aus.
Deshalb besser in die .profile bzw. .bash_profile eintragen.
Für claudette (/home/claudette/.bashrc)
Nun als Nutzer claudette einloggen und dort in die /home/claudette/.bashrc eintragen.
1
2
3
4
5
# als eigener Nutzer eingeloggt, zum Benutzer claudette wechseln
deinuser@box:~$ su - claudette
# nun ist man als claudette eingeloggt und im Homeverzeichnis
claudette@box:~$ echo 'umask 002' >> .bashrc
Auswirkung der umask 002
Die folgende Tabelle zeigt einen Vergleich zwischen den umask-Optionen: links ist die umask 022 (Standard bei Debian-Systemen) und rechts die Version mit gesetzter umask 002.
| Erstellter Typ | Ohne umask 002 | Mit umask 002 |
|---|---|---|
| Datei | 644 (rw-r–r–) |
664 (rw-rw-r–) |
| Verzeichnis | 755 (rwxr-xr-x) |
775 (rwxrwxr-x) |
Git-Repository im gemeinsamen Verzeichnis
Wie anfänglich erwähnt, sollte man zur Prüfung und Nachverfolgung der KI-Agenten-Aktivitäten immer in einem git-Repository arbeiten. Beispielsweise kann man innerhalb des gemeinsamen Arbeitsverzeichnisses ein Unterverzeichnis für git-Projekte erstellen:
1
2
3
# Eingeloggt als claudette ein gemeinsames Basisverzeichnis
# für Projekte erstellen, bspw. im Unterverzeichnis git:
claudette@box:~$ mkdir /home/kiworker/git
Jetzt kann man in diesem Verzeichnis ein git-repo erstellen:
1
2
3
4
5
6
claudette@box:~$ cd /home/kiworker/git
claudette@box:/home/kiworker/git$ git init mein-projekt
claudette@box:/home/kiworker/git$ cd mein-projekt
# Git so konfigurieren, dass es die Gruppe beibehält
claudette@box:/home/kiworker/git/mein-projekt$ git config core.sharedRepository group
core.sharedRepository = group sorgt dafür, dass git alle erstellten Objekte mit Gruppenrechten anlegt –
andernfalls setzt git eigene, restriktivere Rechte.
Bestehende Verzeichnisse ins gemeinsame Verzeichnis kopieren und Rechte/Eigentümer anpassen
Man kann auch ein bestehendes Projektverzeichnis/Repo als eigener Nutzer ins Verzeichnis /home/kiworker/git kopieren. Dabei bleiben aber die originalen Eigentümer und Rechte erhalten.
Für den gemeinsamen Zugriff nach dem Kopieren muss man dies nachträglich korrigieren:
1
2
3
4
5
6
# jeweils im git-Verzeichnis als Nutzer ausführen, der die
# Daten dort hineinkopiert/geclont hat
git config core.sharedRepository group
chmod -R g+rwX .
chgrp -R kiworker .
find . -type d -exec chmod g+s {} +
Der letzte Befehl setzt das Sticky-Bit für alle Verzeichnisse unterhalb des aktuellen Verzeichnisses. Wenn man dies vergisst, erhalten neu erstellte Dateien/Verzeichnisse die Gruppe des Nutzers.
KI-Agent installieren
Zunächst muss man den KI-Agenten noch installieren. Dies sollte ausschließlich im KI-Nutzerkonto erfolgen, sodass man nicht aus Versehen als eigener Nutzer den Agenten startet.
Für Claude-CLI:
1
2
3
4
5
6
7
# als eigener Nutzer eingeloggt, zum Benutzer claudette wechseln
deinuser@box:~$ su - claudette
# Claude-CLI installieren (siehe ggfs. aktuelle
# Installationshinweise auf der claude-Webseite)
claudette@box:~$ curl -fsSL https://claude.ai/install.sh | bash
# danach den Suchpfad für Claude in die .bashrc kopieren
claudette@box:~$ echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc && source ~/.bashrc
Der abschließende Befehl
source ~/.bashrcaktualisiert die Umgebungsvariablen sodassclaudeim Suchpfad ist. Kann man mitwhich claudetesten.
Claude API-Key-Setup / Registrierung
Beim ersten Start fragt Claude nach der Registrierung/Eingabe der Lizenzdaten. Da hierzu ein Webbrowser geöffnet wird empfiehlt es sich, das Registrierungs-Prozedere wie folgt durchzuführen:
- zunächst klassisch via GNOME Desktop mit dem Nutzer claudette einzuloggen
- ein Terminal zu öffnen
claudeausführen und die Fragen zum Style beantworten- dann Registrierungsprozedere durchführen
Wenn Claude erstmal eingerichtet ist, kann man sich wieder ausloggen und fortan im Terminal mit Nutzerwechsel arbeiten.
Zu claudette wechseln und KI starten
Während der Arbeit mit der KI öffnet man ein Terminal, wechselt in den KI Nutzer und fängt an zu arbeiten.
1
2
# su mit Login-Shell (lädt .bashrc/.profile, also auch umask)
deinuser@box:~$ su - claudette
Dateizugriff im laufenden Betrieb prüfen
Die richtigen Zugriffsrechte und Eigentümerschaften kann man wie folgt prüfen:
1
2
3
4
5
6
7
8
9
10
11
12
13
# Neue Datei von claudette erstellt – prüfen:
deinuser@box:~$ ls -la /home/kiworker/git/mein-projekt/
# Erwartetes Ergebnis:
# -rw-rw-r-- 1 claudette kiworker ... neue-datei.txt
# ---------------
# Gruppe schreibberechtigt!
# Als deinuser bearbeiten:
deinuser@box:~$ nano /home/kiworker/git/mein-projekt/neue-datei.txt
# committen
deinuser@box:~$ cd /home/kiworker/git/mein-projekt
deinuser@box:/home/kiworker/git/mein-projekt$ git add . && git commit -m "..."
ACLs als Alternative (optional)
Wenn feingranularere Kontrolle benötigt wird, z.B. ohne SetGID:
1
2
3
4
5
6
7
8
9
10
11
12
13
# Paket installieren (meist vorinstalliert)
sudo apt install acl # Debian/Ubuntu
sudo dnf install acl # Fedora/RHEL
# deinuser bekommt rwx auf das Verzeichnis
sudo setfacl -R -m u:deinuser:rwx /home/kiworker/git
# Standard-ACL für neue Dateien (erben diese Rechte automatisch)
sudo setfacl -R -d -m u:deinuser:rwx /home/kiworker/git
sudo setfacl -R -d -m u:claudette:rwx /home/kiworker/git
# Prüfen:
getfacl /home/kiworker/git
Zusammenfassung
| Was | Einstellung |
|---|---|
| Gemeinsame Gruppe | kiworker |
| Verzeichnisrechte | 2775 (SetGID + rwxrwxr-x) |
| umask beide Nutzer | 002 |
| Git-Repositories | core.sharedRepository = group |
| Nutzerwechsel | su - claudette oder sudo -u claudette claude |
Typischer Workflow
1
2
3
4
5
6
Terminal 1 (deinuser): Terminal 2 (claudette):
cd /home/kiworker/git su - claudette
git log cd /home/kiworker/git
nano README.md claude
git add . && git commit # KI generiert Dateien
git log --oneline # ...mit Gruppenrechten 664
Statt git auf der Kommandozeile zu benutzen, kann und sollte man als eigener Nutzer eher ein GUI Tool verwenden.
Tipps & Tricks
Wirklich geheime Dateien verstecken
Falls man im Repository Dateien mit geheimen Zugangsdaten hat, und diese (verständlicherweise) der KI nicht zur Verfügung stellen will, sollte man:
- Eigentümerschaft auf
deinuser:kiworkerstellen (bspw.chown deinuser:kiworker my-secret-file.txt) - Zugriffsrechte auf nur Nutzer stellen (bspw.
chmod go-rwx publish.sh)
KI Terminal kennzeichnen
Es bietet sich an, die Shell mit der KI (also wo man den Benutzer claudette verwendet) anders einzufärben. Je nach Terminal-Programm kann man das mittels Skript machen, d.h. sich einen Desktop-Shortcut anlegen, der ein Terminal mit gewünschtem Farbprofile öffnet und als allererstes den Befehl su - claudette ausführt und ggfs. danach gleich ins Arbeitsverzeichnis wechselt. Dann ist man nach Eingabe des Nutzerpassworts direkt an Ort und Stelle und kann durch die farbliche Hervorhebung das KI-Terminal von den anderen Konsolenfenstern unterscheiden.