Cosa causa gli errori di autorizzazione solo all'interno dei sottoprocessi degli agenti IA?

Gli errori di autorizzazione che si verificano solo nei sottoprocessi si manifestano quando l'agente avvia processi figlio con un'identità, un ambiente, uno spazio dei nomi, una vista del filesystem o una policy di sicurezza diversi.

Un processo agente può leggere correttamente un file domestico o chiamare uno strumento, per poi ricevere un errore di autorizzazione negata quando la stessa azione viene eseguita tramite una shell, un worker Python, un container o una sandbox. Il processo figlio può perdere gruppi supplementari, credenziali, variabili d'ambiente, capacità, accesso ai socket, visibilità dei mount o permessi di esecuzione. Il testo del comando è identico, ma il suo contesto di sicurezza non lo è.

Il processo figlio può ereditare un set diverso di utenti e credenziali

I launcher possono impostare UID, GID, gruppi supplementari, umask, directory di lavoro, ambiente e descrittori di file. I gestori dei servizi, gli helper setuid, i container e i pool di worker possono ridurre intenzionalmente i privilegi prima di eseguire codice generato. Questa distinzione rimane visibile durante i successivi test in ambiente domestico.

Un'analisi pratica del contesto di sicurezza del processo inizia dai controlli su identità, policy di sicurezza e namespace, invece di presumere che i bit della modalità Unix spieghino tutto. Il segnale distintivo è dato da ID, gruppi, umask o disponibilità delle credenziali diversi all'interno del processo figlio.

Il fatto che un processo padre venga eseguito come root non garantisce un processo figlio senza restrizioni, e gli ID numerici possono essere mappati diversamente nei container o nelle condivisioni di rete. Confronta l'identità effettiva durante la syscall che fallisce. Il risultato intermedio deve rimanere ispezionabile prima che l'automazione proceda.

Namespace, mount e sandbox modificano la vista del filesystem

Un sottoprocesso può entrare in un container o in una sandbox in cui i percorsi sono di sola lettura, nascosti, rimappati, montati con l'opzione noexec o posseduti da un altro ID numerico. I socket Unix e i file dei dispositivi possono essere assenti anche quando i file normali sono visibili.

Un caso pratico di risoluzione dei problemi di una sandbox mostra i permessi dei socket della sandbox quando un processo figlio non riesce ad accedere al socket inoltrato di cui ha bisogno. La lezione è che l'autorizzazione negata può descrivere una policy di connettività o di namespace, non soltanto il contenuto dei file. Questo confine deve essere misurato separatamente in condizioni operative realistiche.

Se il processo figlio vede un inode, opzioni di mount o un percorso diversi, modificare i permessi sull'host potrebbe non avere alcun effetto. Risolvi il percorso e l'identità del mount dall'interno del contesto in cui si verifica l'errore. La conseguenza pratica emerge quando più fonti competono per un contesto limitato.

Le capacità e le policy obbligatorie possono negare operazioni consentite dai bit di modalità

Le capacità Linux suddividono i privilegi di root, mentre SELinux, AppArmor, seccomp e le regole della sandbox possono rifiutare operazioni nonostante i bit di lettura o esecuzione per il proprietario. Le operazioni di rete, ptrace, sui dispositivi e sui mount sono confini comuni. Questa dipendenza deve rimanere esplicita nell'interfaccia finale.

Il modello di capacità ed etichette di sicurezza elenca i controlli UID e GID insieme alle capacità e alle etichette di sicurezza. Questi livelli indipendenti spiegano perché il solo chmod può lasciare invariato l'errore del sottoprocesso. Il risultato deve quindi essere verificato rispetto alle evidenze originali.

Il confine dell'errore è un messaggio di autorizzazione generato dall'applicazione che non corrisponde a un diniego del sistema operativo. Raccogli errno, log di audit e la syscall esatta prima di indebolire la policy della sandbox o rendere i file scrivibili da tutti. Questa distinzione rimane visibile durante i successivi test in ambiente domestico.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Confronta i contesti di sicurezza del processo padre e del processo figlio durante la chiamata che fallisce

Raccogli il percorso dell'eseguibile, gli argomenti, la directory di lavoro, UID, GID, gruppi, umask, i nomi delle variabili d'ambiente, i descrittori di file, gli ID dei namespace, la tabella dei mount, l'inode del percorso, la modalità, l'ACL, l'etichetta di sicurezza, le capacità, lo stato di seccomp, la presenza del socket, errno e la decisione dell'audit nel processo padre e nel processo figlio.

Usa i controlli delle capacità dell'agente per mettere in relazione il risultato con l'ambito degli strumenti dell'agente. Riproduci il problema con un processo figlio minimale e aggiungi nuovamente, uno alla volta, i livelli del launcher, del container e della sandbox. Il risultato intermedio deve rimanere ispezionabile prima che l'automazione proceda.

Concedi solo la capacità, il gruppo, il mount, il socket o il percorso mancanti. Mantieni la restrizione quando riflette l'isolamento previsto; il fallimento del sottoprocesso può essere la prova che il confine di fiducia dell'IA domestica funziona correttamente. Questo confine deve essere misurato separatamente in condizioni operative realistiche.