Was verursacht Berechtigungsfehler nur innerhalb von KI-Agenten-Unterprozessen?

Berechtigungsfehler, die nur bei Unterprozessen auftreten, entstehen, wenn der Agent unter einer anderen Identität, Umgebung, einem anderen Namespace, einer anderen Dateisystemansicht oder einer anderen Sicherheitsrichtlinie Kindprozesse startet.

Ein Agent-Prozess kann möglicherweise eine Datei im Haushalt lesen oder ein Tool erfolgreich aufrufen und anschließend eine Berechtigungsverweigerung erhalten, wenn dieselbe Aktion über eine Shell, einen Python-Worker, einen Container oder eine Sandbox ausgeführt wird. Dem Kindprozess können ergänzende Gruppen, Anmeldedaten, Umgebungsvariablen, Capabilities, Socket-Zugriff, Mount-Sichtbarkeit oder Ausführungsberechtigungen fehlen. Der Befehlstext ist identisch, aber sein Sicherheitskontext ist es nicht.

Das Kind kann einen anderen Benutzer und anderen Anmeldedatensatz erben

Starter können UID, GID, ergänzende Gruppen, umask, Arbeitsverzeichnis, Umgebung und Dateideskriptoren festlegen. Dienstmanager, setuid-Hilfsprogramme, Container und Worker-Pools können Berechtigungen absichtlich reduzieren, bevor sie generierten Code ausführen. Dieser Unterschied bleibt bei späteren Tests im Haushalt sichtbar.

Eine praktische Analyse des Sicherheitskontexts eines Prozesses beginnt mit Prüfungen von Identität, Sicherheitsrichtlinie und Namespace, statt anzunehmen, dass Unix-Modusbits die gesamte Situation erklären. Typisch sind eine andere ID, andere Gruppen, eine andere umask oder eine andere Verfügbarkeit von Anmeldedaten im Kindprozess.

Ein übergeordneter Prozess, der als root läuft, garantiert kein uneingeschränktes Kind, und numerische IDs können Containern oder Netzwerkfreigaben unterschiedlich zugeordnet sein. Vergleichen Sie die effektive Identität am fehlschlagenden Systemaufruf. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung fortgesetzt wird.

Namespaces, Mounts und Sandboxes verändern die Dateisystemansicht

Ein Unterprozess kann in einen Container oder eine Sandbox wechseln, in dem Pfade schreibgeschützt, verborgen, neu zugeordnet, mit noexec gemountet oder einer anderen numerischen ID zugeordnet sind. Unix-Sockets und Gerätedateien können fehlen, selbst wenn reguläre Dateien sichtbar sind.

Ein Fall zur Fehlerbehebung bei einer Sandbox zeigt Sandbox-Socket-Berechtigungen, wenn ein Kindprozess nicht auf den weitergeleiteten Socket zugreifen kann, den er benötigt. Die Lehre daraus ist, dass eine Berechtigungsverweigerung Konnektivität oder eine Namespace-Richtlinie beschreiben kann und nicht nur Dateiinhalte. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.

Wenn das Kind einen anderen Inode, andere Mount-Optionen oder einen anderen Pfad sieht, wirkt sich eine Änderung der Host-Berechtigungen möglicherweise nicht auf ihn aus. Lösen Sie Pfad und Mount-Identität aus dem fehlschlagenden Kontext heraus auf. Die praktische Konsequenz wird sichtbar, wenn mehrere Quellen um einen begrenzten Kontext konkurrieren.

Capabilities und verpflichtende Richtlinien können zulässige Modusbits verweigern

Linux-Capabilities teilen Root-Berechtigungen auf, während SELinux, AppArmor, seccomp und Sandbox-Regeln Vorgänge trotz Lese- oder Ausführungsberechtigungen des Besitzers ablehnen können. Netzwerk-, ptrace-, Geräte- und Mount-Vorgänge sind häufige Grenzen. Diese Abhängigkeit sollte in der finalen Schnittstelle ausdrücklich erhalten bleiben.

Das Modell für Capabilities und Sicherheitslabels führt UID- und GID-Steuerungen neben Capabilities und Sicherheitslabels auf. Diese unabhängigen Ebenen erklären, warum chmod allein den Fehler im Unterprozess unverändert lassen kann. Das Ergebnis muss daher anhand der ursprünglichen Belege überprüft werden.

Die Fehlergrenze liegt bei einer von der Anwendung erzeugten Berechtigungsmeldung, die keiner Ablehnung durch das Betriebssystem entspricht. Erfassen Sie errno, Audit-Protokolle und den exakten Systemaufruf, bevor Sie die Sandbox-Richtlinie abschwächen oder Dateien für alle Benutzer beschreibbar machen. Dieser Unterschied bleibt bei späteren Tests im Haushalt sichtbar.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vergleichen Sie die Sicherheitskontexte von übergeordnetem Prozess und Kindprozess beim fehlschlagenden Aufruf

Erfassen Sie in übergeordnetem Prozess und Kindprozess den Pfad der ausführbaren Datei, Argumente, cwd, UID, GID, Gruppen, umask, Namen der Umgebungsvariablen, Dateideskriptoren, Namespace-IDs, Mount-Tabelle, Pfad-Inode, Modus, ACL, Sicherheitslabel, Capabilities, seccomp-Status, Socket-Vorhandensein, errno und die Audit-Entscheidung.

Verwenden Sie Capability-Steuerungen für Agenten, um das Ergebnis mit dem Umfang der Agenten-Tools in Beziehung zu setzen. Reproduzieren Sie den Fehler mit einem minimalen Kindprozess und fügen Sie die Ebenen von Starter, Container und Sandbox nacheinander wieder hinzu. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung fortgesetzt wird.

Gewähren Sie nur die fehlende Capability, Gruppe, den fehlenden Mount, Socket oder Pfad. Behalten Sie die Einschränkung bei, wenn sie die beabsichtigte Isolation widerspiegelt; ein Fehler im Unterprozess kann ein Hinweis darauf sein, dass die Vertrauensgrenze der heimischen KI ordnungsgemäß funktioniert. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.