Migliori Pratiche per la Sicurezza dei Filesystem Linux con Permessi Speciali

I permessi speciali sono una di quelle funzionalità di Linux che sembrano piccole in ls -l ma contano molto in produzione. Una s extra su un binario di proprietà di root può consentire agli utenti ordinari di eseguire un'attività privilegiata limitata. Una t mancante su una directory di upload condivisa può permettere agli utenti di eliminare i file degli altri. Un bit SGID su una directory di progetto può farti risparmiare un flusso costante di problemi di proprietà del gruppo.

L'obiettivo non è spargere bit speciali ovunque. L'obiettivo è sapere quando SUID, SGID e lo sticky bit risolvono un problema di accesso reale, e quando creano un percorso di privilegio che rimpiangerai in seguito.

Riepilogo dei Permessi Standard

Prima di esplorare i permessi speciali, è essenziale ricordare la notazione standard a triplette (rwx per proprietario, gruppo e altri). Questi permessi sono rappresentati numericamente utilizzando valori ottali (ad esempio, 755 o 644).

r (Lettura) = 4
w (Scrittura) = 2
x (Esecuzione) = 1

I permessi speciali modificano questo comportamento di base e sono rappresentati da una quarta cifra ottale iniziale (4, 2 o 1).

I Permessi Speciali: SUID, SGID e Sticky Bit

I permessi speciali aggiungono funzionalità oltre il controllo di accesso standard. Di solito sono indicati nell'output del listato lungo (ls -l) da una s o t che sostituisce il flag x standard.

Permesso	Valore Ottale	Effetto
SUID (Set User ID)	4	Il file viene eseguito con i permessi del proprietario del file (non dell'utente che lo esegue).
SGID (Set Group ID)	2	Il file viene eseguito con i permessi del gruppo del file, oppure i nuovi file ereditano il gruppo della directory padre.
Sticky Bit	1	Impedisce agli utenti di eliminare o rinominare file di proprietà di altri utenti in una directory condivisa, anche se hanno il permesso di scrittura sulla directory.

1. Set User ID (SUID)

Il bit SUID è potente e potenzialmente pericoloso se usato male. Quando impostato su un file eseguibile, qualsiasi utente che esegue quel file avvia il processo con i permessi del proprietario.

Caso d'Uso Pratico: Utility che richiedono privilegi di root per eseguire un'attività specifica, ma non dovrebbero concedere all'utente un accesso root generale.

Esempio: SUID su `/usr/bin/passwd`

Il comando /usr/bin/passwd richiede tipicamente l'accesso root per modificare il file sicuro /etc/shadow. Ha il bit SUID impostato, consentendo a un utente standard di ottenere temporaneamente i privilegi del proprietario (root) solo per la durata dell'esecuzione di passwd per cambiare la propria password.

Visualizzare SUID: Nota la s nello slot di esecuzione del proprietario:

ls -l /usr/bin/passwd
# Esempio di output: -rwsr-xr-x 1 root root ... /usr/bin/passwd

Impostare SUID: Usa il valore ottale 4 combinato con i permessi standard (ad esempio, 755 diventa 4755):

# Supponendo che 'my_script' sia di proprietà di 'appuser'
chmod 4755 /path/to/my_script

Avviso di Sicurezza per SUID: Non impostare mai il bit SUID su shell generiche (come /bin/bash) o script di manutenzione ampi che interpretano input esterni. Se uno script necessita di privilegi, una regola sudoers ristretta, un piccolo helper revisionato o un'API di servizio sono solitamente più sicuri.

Quando fai un audit su un host, i file SUID meritano attenzione perché sono attraversamenti di privilegi intenzionali:

sudo find / -xdev -type f -perm -4000 -ls 2>/dev/null

-xdev mantiene la scansione sul filesystem corrente, il che è utile quando /proc, backup montati o filesystem di rete renderebbero il risultato rumoroso. Su server con mount separati, scansiona ogni filesystem reale intenzionalmente.

2. Set Group ID (SGID)

Il bit SGID ha due funzioni principali a seconda che sia applicato a un file o a una directory.

A. SGID su File Eseguibili

Quando impostato su un file eseguibile, il processo viene eseguito con i permessi associati alla proprietà del gruppo del file, non al gruppo primario dell'utente.

B. SGID su Directory (Cruciale per Ambienti Condivisi)

Quando impostato su una directory, qualsiasi nuovo file o sottodirectory creato al suo interno eredita automaticamente la proprietà del gruppo della directory padre, anziché il gruppo primario dell'utente che ha creato il nuovo file.

Caso d'Uso Pratico: Cartelle di progetto condivise dove tutti i contributori devono avere accesso unificato al gruppo per la collaborazione.

Impostare SGID su una Directory: Usa il valore ottale 2 combinato con i permessi standard (ad esempio, 775 diventa 2775):

# Imposta la proprietà del gruppo su 'developers' e abilita SGID
chgrp developers /srv/shared_project
chmod 2775 /srv/shared_project

Questo gestisce l'ereditarietà del gruppo, ma non garantisce che ogni nuovo file sia scrivibile dal gruppo. L'umask di un utente conta ancora. Se i contributori creano file con un umask restrittivo come 077, i file potrebbero ereditare il gruppo developers ma essere comunque illeggibili o non scrivibili dal gruppo. Per le directory condivise, controlla l'umask previsto, gli ACL predefiniti o le impostazioni di creazione dei file a livello di applicazione:

getfacl /srv/shared_project
setfacl -d -m g:developers:rwx /srv/shared_project

Gli ACL predefiniti sono spesso il pezzo mancante nelle directory collaborative perché applicano i permessi ai nuovi file e directory creati all'interno del percorso.

3. Lo Sticky Bit

Lo Sticky Bit (o Attributo Salva Testo) è usato quasi esclusivamente su directory condivise per controllare l'eliminazione dei file.

Quando lo Sticky Bit è impostato su una directory, solo il proprietario di un file all'interno di quella directory, o l'utente root, possono eliminare o rinominare quel file, anche se la directory stessa consente l'accesso in scrittura per 'altri' (o+w).

Caso d'Uso Pratico: Directory pubbliche condivise come /tmp o cartelle di upload dipartimentali dove gli utenti dovrebbero poter gestire solo i file che hanno creato.

Esempio: La Directory `/tmp`

La directory /tmp ha spesso permessi come 1777. Il 1 indica che lo Sticky Bit è attivo.

ls -ld /tmp
# Esempio di output: drwxrwxrwt 15 root root 4096 Mar 10 11:30 /tmp

La t alla fine conferma che lo sticky bit è impostato. Senza di esso, qualsiasi utente potrebbe eliminare i file creati da altri utenti in /tmp.

Impostare lo Sticky Bit: Usa il valore ottale 1 combinato con i permessi standard (ad esempio, 777 diventa 1777):

chmod 1777 /var/public_uploads

Gestione Completa: Combinare i Permessi Speciali

I permessi speciali sono spesso combinati. La quarta cifra iniziale è la somma dei bit speciali desiderati (4+2+1 = 7).

Permessi Desiderati	Valore Ottale
Standard `rwxr-xr-x` (755)	`755`
SUID + `rwxr-xr-x`	`4755`
SGID + `rwxr-xr-x`	`2755`
Sticky Bit + `rwxrwxrwx`	`1777`
SUID + SGID + Sticky Bit + `rwx` (Raramente necessario)	`7777`

Esempio di Combinazione di SGID e Sticky Bit per Cartelle Condivise:

Per creare una directory di collaborazione condivisa e sicura dove tutti gli utenti fanno parte del gruppo 'team', i nuovi file ereditano il gruppo 'team' e gli utenti non possono eliminare i file degli altri:

Imposta la proprietà del gruppo: chgrp team /data/projectX
Applica SGID (2) + Standard rwx (7) + Sticky Bit (1) $\rightarrow 2+1 = 3$ per i bit speciali.
- Usando la somma esplicita: SGID (2) + Sticky Bit (1) = 3. Permessi standard 775.
- Comando totale: chmod 3775 /data/projectX

Quando visualizzi questo con ls -ld, dovresti vedere sia s nella posizione di esecuzione del gruppo che t nella posizione di esecuzione degli altri:

drwxrwsr-t 2 root team 4096 Mar 10 11:30 /data/projectX

Se il bit di esecuzione manca, la visualizzazione usa la S o T maiuscola. Di solito è un segnale di avvertimento sulle directory, perché il permesso di esecuzione controlla se gli utenti possono attraversare la directory.

Errori Comuni che Causano Incidenti Reali

L'errore più pericoloso è usare SUID per evitare di progettare un'autorizzazione adeguata. Se uno script di manutenzione deve ruotare un file di proprietà dell'applicazione, non rendere l'intero script effettivamente root per ogni utente. Dai all'applicazione un comando di servizio controllato, usa una regola sudoers ristretta o cambia la proprietà in modo che l'account di servizio possa eseguire l'attività senza root.

Un altro errore comune è rendere le directory condivise scrivibili da tutti senza lo sticky bit:

chmod 777 /srv/uploads

Sembra conveniente durante i test. In produzione, qualsiasi utente locale che può raggiungere la directory potrebbe essere in grado di rinominare o eliminare i file di un altro utente. Se la directory deve davvero essere scrivibile da molti utenti non correlati, 1777 è di solito la base più sicura:

chmod 1777 /srv/uploads

Per le directory di proprietà del team, 2775 più un gruppo reale è spesso meglio della scrittura mondiale. Aggiungi lo sticky bit solo se i membri del team non devono eliminare i file degli altri. Alcuni team vogliono diritti di pulizia condivisi; altri no. Il modello di permessi dovrebbe corrispondere a quel flusso di lavoro.

Anche i backup e le distribuzioni possono rompere i permessi speciali. Alcuni strumenti di archiviazione e copia preservano le modalità per impostazione predefinita; altri no a meno che non si passino i flag giusti. Dopo aver ripristinato un sistema o distribuito un pacchetto binario, verifica esplicitamente i bit speciali:

stat -c '%A %a %U %G %n' /usr/bin/passwd /tmp /srv/shared_project

Se /tmp torna come 0777 invece di 1777, non è una differenza estetica. Gli utenti possono interferire con i file degli altri. Se un bit SUID richiesto manca su un'utility di sistema, gli utenti ordinari potrebbero improvvisamente perdere il comportamento previsto. Se un bit SUID inaspettato appare su un file in /home, /tmp o un percorso di upload dell'applicazione, trattalo come sospetto fino a prova contraria.

Audit Senza Annegare nell'Output

Una scansione completa del filesystem può essere rumorosa, specialmente su macchine di build e workstation di sviluppatori. Inizia con le aree che contano di più:

sudo find /usr /bin /sbin /opt -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null
sudo find /tmp /var/tmp /dev/shm -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null

Il primo comando esamina le posizioni normali degli eseguibili. Il secondo controlla le aree di scratch scrivibili dove un eseguibile privilegiato sarebbe molto più preoccupante. Su un server pulito, i file SUID personalizzati in percorsi scrivibili da tutti dovrebbero essere rari. Se ne trovi uno, controlla la proprietà, la fonte del pacchetto, l'ora di modifica e se appare nella tua gestione della configurazione.

Per le directory, cerca percorsi scrivibili da tutti senza lo sticky bit:

sudo find / -xdev -type d -perm -0002 ! -perm -1000 -ls 2>/dev/null

Questo non significa che ogni risultato sia una violazione. Significa che ogni risultato merita una ragione. Alcune directory di applicazioni sono intenzionalmente scrivibili da un gruppo di servizio, ma le directory pubbliche scrivibili senza protezione sticky sono una comune trappola.

Migliori Pratiche per la Sicurezza dei Permessi Speciali

A causa dei privilegi elevati che SUID e SGID concedono, devono essere gestiti con estrema cautela.

Limita l'Ambito di SUID: Imposta SUID solo su eseguibili binari compilati necessari per le operazioni standard (come passwd, ping). Non applicare mai SUID a script interpretati (Shell, Python, Perl) a meno che non siano racchiusi in un eseguibile wrapper sicuro che convalida l'input.

Audit Regolare: Scansiona periodicamente il filesystem per file SUID/SGID insoliti usando il comando find:

# Trova tutti i file con SUID impostato
find / -perm /4000 2>/dev/null
# Trova tutti i file con SGID impostato
find / -perm /2000 2>/dev/null

Usa SGID per la Coerenza del Gruppo: Preferisci SGID rispetto alla gestione manuale della proprietà del gruppo dei file nelle strutture dati condivise; automatizza l'ereditarietà del gruppo.
Sticky Bit per Aree Scrivibili Pubbliche: Lo Sticky Bit è essenziale per qualsiasi directory destinata all'uso generale da parte degli utenti dove l'eliminazione da parte di non proprietari deve essere limitata (ad esempio, /tmp, /var/tmp).
Abbina SGID con ACL quando la collaborazione è importante: SGID gestisce la proprietà del gruppo; gli ACL predefiniti gestiscono i permessi che i nuovi file ricevono.
Tieni Traccia delle Eccezioni Personalizzate: Se la tua organizzazione approva un binario SUID o SGID personalizzato, registra lo scopo, il proprietario, il percorso previsto e la fonte di distribuzione. Il privilegio misterioso è la parte che fa male dopo.

I permessi speciali sono utili perché sono precisi. Mantienili tali. Usa SUID per transizioni di privilegio ristrette, SGID per la proprietà condivisa e lo sticky bit per le directory condivise dove i diritti di eliminazione necessitano di protezioni.