Autorizzazioni sui file in Linux

Ciao a tutti. Ci stiamo mettendo attivamente al lavoro e stiamo già preparando molti potenti lanci a gennaio. Tra gli altri, è stata annunciata l'iscrizione per un nuovo streaming del corso preferito da tutti. "Amministratore Linux". In previsione del lancio, tradizionalmente condividiamo le traduzioni di materiale utile.

I permessi dei file offrono un'alternativa sicura agli eseguibili SUID, ma all'inizio possono sembrare un po' confusi.

Sappiamo tutti che i binari SUID sono pessima decisione dal punto di vista della sicurezza. Fortunatamente, se la tua applicazione richiede alcuni privilegi limitati, esiste un modo più efficiente chiamato permessi dei file.

Ti farò risparmiare un po' di tempo se vuoi evitare di leggere l'articolo sopra in dettaglio: Essenzialmente, i permessi dei file consentono processi che vengono eseguiti come root e sono quindi autorizzati a fare qualcosa per mantenere determinate capacità, limitate questo elencoquando perdono i privilegi e vengono eseguiti da un utente non privilegiato. Ciò significa che se un utente malintenzionato riesce a compromettere un processo utilizzando un buffer overflow o un altro exploit, non sarà in grado di sfruttare nient'altro che alcuni privilegi minimi di cui il processo ha effettivamente bisogno.

Le autorizzazioni sono ottime per i servizi che in genere vengono sempre eseguiti come root, ma per quanto riguarda le utilità della riga di comando? Fortunatamente, anche questo è supportato a condizione che siano installate le utilità giuste. Se usi Ubuntu, ad esempio, avrai bisogno del pacchetto libcap2-bin. Sarà inoltre necessario eseguire un kernel non arcaico (dalla versione 2.6.24).

Queste funzioni consentono di associare i permessi ai file eseguibili, in modo simile all'impostazione del bit SUID, ma solo per un insieme specifico di permessi. Utilità setcap utilizzato per aggiungere e rimuovere autorizzazioni da un file.

Il primo passo è selezionare le autorizzazioni necessarie. Ai fini di questo articolo, presumo che esista uno strumento di diagnostica di rete chiamato tracewalk, che dovrebbe essere in grado di utilizzare prese grezze. Ciò di solito richiede che l'applicazione venga eseguita come root, ma durante la visualizzazione l'elenco si scopre che è richiesta solo l'autorizzazione CAP_NET_RAW.

Supponendo che tu sia nella directory in cui si trova il file binario tracewalk, puoi aggiungere questa autorizzazione in questo modo:

sudo setcap cap_net_raw=eip tracewalk

Ignora il suffisso per ora =eip per la risoluzione, ne parlerò tra un paio di secondi. Tieni presente che il nome dell'autorizzazione è in minuscolo. Ora puoi verificare se hai configurato correttamente i permessi con:

setcap -v cap_new_raw=eip tracewalk

Oppure puoi elencare tutte le autorizzazioni impostate per un determinato eseguibile:

getcap tracewalk

Per riferimento, puoi anche rimuovere tutte le autorizzazioni dall'eseguibile con:

setcap -r tracewalk

A questo punto, dovresti essere in grado di eseguire l'eseguibile come utente senza privilegi e dovrebbe essere in grado di funzionare con socket raw, ma non avere nessuno degli altri privilegi di cui dispone l'utente root.

Allora cosa significa questo strano suffisso? =eip? Ciò richiede una certa comprensione della natura delle autorizzazioni. Ogni processo ha tre serie di permessi − efficace, ereditabile e consentito:

• Efficace I permessi sono quelli che definiscono cosa può effettivamente fare un processo. Ad esempio, non può gestire i socket grezzi if CAP_NET_RAW non è nell'insieme effettivo.
• Disponibile i permessi sono quelli che un processo può avere se li richiede utilizzando l'apposita chiamata. Impediscono a un processo di fare effettivamente qualcosa a meno che non sia stato specificamente scritto per richiedere tale autorizzazione. Ciò consente di scrivere processi per aggiungere autorizzazioni critiche al set effettivo solo per il periodo in cui sono effettivamente richieste.
• Ereditarietà le autorizzazioni sono quelle che possono essere ereditate nell'insieme accessibile del processo figlio generato. Durante l'intervento chirurgico fork() o clone() al processo figlio viene sempre fornita una copia dei permessi del processo genitore poiché a quel punto sta ancora eseguendo lo stesso eseguibile. Un set ereditabile viene utilizzato quando exec() (o equivalente) viene chiamato per sostituire il file eseguibile con un altro. A questo punto l'insieme disponibile del processo viene mascherato dall'insieme ereditabile per ottenere l'insieme accessibile che verrà utilizzato per il nuovo processo.

Quindi l'utilità setcap ci permette di aggiungere i permessi di questi tre set in modo indipendente per un dato eseguibile. Tieni presente che il significato dei gruppi viene interpretato in modo leggermente diverso per i permessi dei file:

• disponibile i permessi dei file sono quelli che sono sempre disponibili per un file eseguibile, anche se il processo genitore che lo ha chiamato non li aveva. Un tempo si chiamavano permessi “forzati”.
• Ereditato i permessi dei file definiscono una maschera aggiuntiva che può essere utilizzata anche per rimuovere i permessi dal set del processo chiamante. Si applicano in aggiunta all'insieme ereditato del processo chiamante, quindi l'autorizzazione viene ereditata solo se esiste in entrambi gli insiemi.
• Efficace i permessi dei file sono in realtà solo un singolo bit, non un set e, se impostati, significa che l'intero set disponibile viene copiato anche nel set effettivo del nuovo processo. Questo può essere utilizzato per aggiungere autorizzazioni a processi che non sono stati scritti specificatamente per richiederle. Poiché è un bit, se lo imposti per qualsiasi autorizzazione, deve essere impostato per tutte le autorizzazioni. Puoi considerarlo un bit legacy perché viene utilizzato per consentire l'utilizzo delle autorizzazioni da parte di applicazioni che non le supportano.

Quando si specificano le autorizzazioni tramite setcap tre lettere e, i и p fare riferimento a efficace, ereditabile e accessibile imposta rispettivamente. Quindi, la specifica precedente:

sudo setcap cap_net_raw=eip tracewalk

...indica che la risoluzione CAP_NET_RAW deve essere aggiunto ai set disponibili ed ereditabili e deve essere impostato anche il bit effettivo. Ciò sovrascriverà tutte le autorizzazioni precedentemente impostate sul file. Per impostare più autorizzazioni contemporaneamente, utilizza un elenco separato da virgole:

sudo setcap cap_net_admin,cap_net_raw=eip tracewalk

Guida alle autorizzazioni discute tutto questo in modo più dettagliato, ma spero che questo post abbia demistificato un po' quello che sta succedendo. Rimangono solo alcuni avvertimenti e trucchi da menzionare.

Innanzitutto, le funzionalità dei file non funzionano con i collegamenti simbolici: devi applicarle al file binario stesso (ovvero la destinazione del collegamento simbolico).

In secondo luogo, non funzionano con script interpretati. Ad esempio, se disponi di uno script Python a cui desideri assegnare l'autorizzazione, devi assegnarlo all'interprete Python stesso. Ovviamente questo è un potenziale problema di sicurezza perché in tal caso tutti gli script eseguiti con quell'interprete avranno il permesso specificato, sebbene questo sia comunque significativamente migliore che renderlo SUID. La soluzione più comune sembra essere quella di scrivere un eseguibile separato in C o equivalente in grado di eseguire le operazioni necessarie e chiamarlo da uno script. Questo è simile all'approccio utilizzato da Wireshark che utilizza un binario /usr/bin/dumpcap per eseguire operazioni privilegiate:

$ getcap /usr/bin/dumpcap 
/usr/bin/dumpcap = cap_net_admin,cap_net_raw+eip

Terzo, i permessi dei file sono disabilitati se usi una variabile d'ambiente LD_LIBRARY_PATH per ovvi motivi di sicurezza(1). Lo stesso vale per LD_PRELOAD, per quanto ne so.

1. Poiché un utente malintenzionato può ovviamente sostituire una delle librerie standard e utilizzare LD_LIBRARY_PATHforzare la chiamata della propria libreria rispetto a quella di sistema, e quindi l'esecuzione del proprio codice arbitrario con gli stessi privilegi dell'applicazione chiamante.

È tutto. Maggiori dettagli sul programma del corso sono reperibili su webinar, che si svolgerà il 24 gennaio.

Fonte: habr.com