Come si può sapere se un file binario è sicuro per concedere autorizzazioni sudo a un utente non attendibile?

In generale, è impossibile saperlo con certezza (anche un programma apparentemente perfettamente sicuro potrebbe avere delle vulnerabilità che significano che può essere utilizzato per azioni arbitrarie), ma ecco alcune cose da controllare:

Il programma esegue una delle seguenti operazioni?

• Rivela il contenuto di file o dispositivi arbitrari.
• Copia, sposta, scrivi o elimina file arbitrari.
• Imposta/modifica variabili di ambiente arbitrarie (che verranno raccolte da altri processi privilegiati) o apporta modifiche arbitrarie a quelle specifiche.
• Invocare IOCTL o interagire in altro modo con dispositivi arbitrari.
• Cambia la proprietà o le autorizzazioni su file arbitrari.
• Monta file system arbitrari o modifica le opzioni di montaggio su quelli esistenti.
• Consenti l'accesso diretto alla memoria del sistema o di un processo arbitrario (come un debugger).
• Consenti l'avvio di programmi arbitrari.

Qualsiasi programma che fa una di queste cose non sicuro per concedere sudo a un utente con privilegi limitati accesso a. Questo esclude, ad esempio, qualsiasi programma con la capacità di specificare un file di output (di solito tramite un -o o -f parametro), elaborare un file di input in qualsiasi modo che ne riveli il contenuto (anche solo tramite un messaggio di errore sufficientemente informativo sul formato di input errato) e la stragrande maggioranza dei runtime di script (comprese le shell).

Se sostituisci arbitrario in quei controlli con limitato o specifico , allora hai risolto il problema di un passaggio (o più):fai una qualsiasi delle cose che il programma può portare a tali avvenimenti arbitrari, possibilmente attraverso molteplici livelli di indiretto? Ad esempio, se il tuo programma consente all'utente di impostare una variabile di ambiente univoca, ciò farà sì che un programma privilegiato legga un file diverso da quello previsto e quel file diverso farà in modo che il sistema consenta agli utenti di montare un file immagine di loro scelta come un file system con setuid un po' rispettato, allora non devi permettere a utenti non fidati di eseguire quel programma.

Tuttavia, solo perché un programma supera tutti questi controlli non significa che sia effettivamente sicuro. Ad esempio, se esegue determinate azioni di rete (come l'ascolto su porte limitate o l'invio di pacchetti grezzi), potrebbe non essere sicuro perché potrebbe esserci un altro programma sulla rete (o sulla stessa macchina) supponendo che ogni processo in grado di eseguire tale operazione things è di proprietà di un utente fidato - dopo tutto, quelle azioni richiedono root - e hai infranto questo presupposto. Inoltre, l'elenco degli elenchi puntati sopra è solo roba a cui ho pensato in pochi minuti; ci sono quasi certamente alcune strade per privilegiare l'escalation che non ho incluso.

Infine, come per tutte le domande di sicurezza, dipende dal tuo modello di minaccia.

• L'aggressore (utente non attendibile) è locale alla macchina con accesso fisico o è remoto? È estremamente difficile impedire a un utente malintenzionato determinato con accesso fisico di ottenere il root, soprattutto se deve essere in grado di (ri)avviare la macchina senza assistenza, quindi considera quali rischi sei disposto ad accettare.
• La macchina è condivisa tra gli utenti? Quindi è necessario considerare ulteriori attacchi tra utenti, come il denial-of-service (consumando risorse eccessive o rendendo inutilizzabile la macchina).
• Richiedi il non ripudio (la capacità di provare chi ha fatto qualcosa)? Quindi devi assicurarti di poter legare qualsiasi azione eseguita tramite sudo all'utente che li ha eseguiti.
• Hai bisogno di impedire all'utente di fare alcune cose che anche un utente non root di solito può fare (come eseguire programmi arbitrari nel proprio contesto utente anche se quei programmi sono cose come giochi o cryptominer, o aprire client TCP connessioni a host e porte arbitrari)? Quindi devi considerare anche i mezzi con cui stai applicando questa restrizione e impedire l'esecuzione come sudo di qualsiasi programma che potrebbe consentire all'utente di aggirare la restrizione.

Ecc. Una risposta veramente esauriente non sarà possibile qui; dipende da troppe cose. Tuttavia, dirò questo:è molto difficile per garantire che un utente non fidato, data la possibilità di eseguire come root qualsiasi programma non banale (che non è stato esplicitamente progettato per essere eseguito in modo sicuro in quel modo), non possa fare qualcosa di inaspettato. Anche se uno di questi programmi non consente nulla che ritieni importante impedire, potrebbe essere possibile concatenare più di questi programmi insieme per raggiungere l'obiettivo dell'attaccante.

Essenzialmente si riduce al problema dell'arresto, puoi controllare il codice o decodificare il binario, tuttavia anche se non ci sono "funzionalità" che ti consentono di eseguire comandi arbitrari, potrebbero comunque esserci vulnerabilità nel binario o sudo stesso che potrebbero portare a esecuzione arbitraria di comandi come root per gli utenti abilitati.