Vad orsakar behörighetsfel endast i AI-agentens underprocesser?
Behörighetsfel som bara uppstår i delprocesser inträffar när agenten startar underordnade processer med en annan identitet, miljö, namnrymd, filsystemsvy eller säkerhetspolicy.
En agentprocess kan läsa en fil i hemmet eller anropa ett verktyg utan problem, men sedan få meddelandet att åtkomst nekas när samma åtgärd körs via ett skal, en Python-arbetare, en container eller en sandlåda. Den underordnade processen kan förlora kompletterande grupper, autentiseringsuppgifter, miljövariabler, funktioner, åtkomst till sockets, synlighet för monteringar eller körbehörighet. Kommandotexten är identisk, men säkerhetskontexten är det inte.
Den underordnade processen kan ärva en annan uppsättning användare och autentiseringsuppgifter
Startprogram kan ange UID, GID, kompletterande grupper, umask, arbetskatalog, miljö och filbeskrivare. Tjänstehanterare, setuid-hjälpprogram, containrar och arbetarpooler kan avsiktligt sänka behörigheterna innan genererad kod körs. Denna skillnad förblir synlig vid senare tester i hemmet.
En praktisk analys av processens säkerhetskontext börjar med kontroller av identitet, säkerhetspolicy och namnrymd, i stället för att anta att Unix-behörighetsbitarna berättar hela historien. Signaturen är ett annat id, andra grupper, en annan umask eller andra tillgängliga autentiseringsuppgifter inuti den underordnade processen.
Att en överordnad process körs som root garanterar inte en obegränsad underordnad process, och numeriska ID:n kan mappas olika i containrar eller på nätverksresurser. Jämför den effektiva identiteten vid det systemanrop som misslyckas. Det mellanliggande resultatet måste förbli inspekterbart innan automatisering fortsätter.
Namnrymder, monteringar och sandlådor ändrar filsystemsvyn
En delprocess kan gå in i en container eller sandlåda där sökvägar är skrivskyddade, dolda, ommappade, monterade med noexec eller ägs av ett annat numeriskt ID. Unix-sockets och enhetsfiler kan saknas även när vanliga filer verkar finnas.
Ett fall av sandlådeproblematik visar socketbehörigheter i sandlådan när en underordnad process inte kan komma åt den vidarebefordrade socket den behöver. Lärdomen är att åtkomst nekad kan beskriva anslutnings- eller namnrymdspolicy, inte bara filinnehåll. Den gränsen bör mätas separat under realistiska driftsförhållanden.
Om den underordnade processen ser en annan inode, andra monteringsalternativ eller en annan sökväg kanske ändrade värdbehörigheter inte påverkar den. Lös sökvägen och monteringsidentiteten inifrån den felande kontexten. Den praktiska konsekvensen blir tydlig när flera källor konkurrerar om en begränsad kontext.
Funktioner och obligatoriska policyer kan neka åtgärder trots tillåtna behörighetsbitar
Linux-funktioner delar upp root-behörigheter, medan SELinux, AppArmor, seccomp och sandlåderegelverk kan avvisa åtgärder trots läs- eller körbitar för ägaren. Nätverk, ptrace, enheter och monteringar är vanliga gränser. Detta beroende bör förbli explicit i det slutliga gränssnittet.
Modellen för funktioner och säkerhetsetiketter listar UID- och GID-kontroller tillsammans med funktioner och säkerhetsetiketter. Dessa oberoende lager förklarar varför chmod ensamt kan lämna delprocessfelet oförändrat. Resultatet måste därför kontrolleras mot de ursprungliga bevisen.
Felgränsen är ett programgenererat behörighetsmeddelande som inte motsvarar ett avslag från operativsystemet. Fånga errno, granskningsloggar och det exakta systemanropet innan du försvagar sandlådans policy eller gör filer skrivbara för alla. Denna skillnad förblir synlig vid senare tester i hemmet.
Jämför den överordnade och underordnade processens säkerhetskontexter vid det anrop som misslyckas
Samla in körbar sökväg, argument, aktuell arbetskatalog, UID, GID, grupper, umask, miljönamn, filbeskrivare, namnrymds-ID:n, monteringstabell, sökvägens inode, läge, ACL, säkerhetsetikett, funktioner, seccomp-tillstånd, socketens närvaro, errno och granskningsbeslut i den överordnade och underordnade processen.
Använd agentens funktionskontroller för att koppla resultatet till agentens verktygsomfattning. Återskapa problemet med en minimal underordnad process och lägg sedan tillbaka startprograms-, container- och sandlådelagren ett i taget. Det mellanliggande resultatet måste förbli inspekterbart innan automatisering fortsätter.
Bevilja endast den funktion, grupp, montering, socket eller sökväg som saknas. Behåll begränsningen när den återspeglar avsedd isolering; ett delprocessfel kan vara ett tecken på att förtroendegränsen för AI i hemmet fungerar korrekt. Den gränsen bör mätas separat under realistiska driftsförhållanden.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Vad får en AI-agentplanerare att upprepa steg som den redan har slutfört?
Spåra upprepade planeringssteg genom tillståndsbeständighet, slutförandebevis, tolkning av verktygsresultat, kontextbevarande, nya försök, omplanering och stoppvillkor.
Vad orsakar CPU-mättnad när hårdvarutranskodning och video-AI körs samtidigt?
Spåra CPU-mättnad i codec-offload, pixelkonvertering, bildkopiering, AI-förbehandling, ljud, undertexter, lagring och processchemaläggning.
Vad får samma lokala LLM att returnera inkonsekventa JSON-scheman?
Diagnostisera inkonsekvent lokal JSON genom att låsa modellväg, prompt, schema, avkodningsbegränsningar, sampling, kontext, stoppvillkor och reparationslager.
