È sicuro consentire a www-data di eseguire comandi privilegiati?

Questo ... è atroce. Il punto intero di esecuzione di oggetti Web come utente non root è il contenimento dei danni: nel caso in cui il processo del server Web venga dirottato attraverso alcune vulnerabilità, almeno l'autore dell'attacco non ottenere il pieno controllo della macchina, poiché sarà vincolato dalle limitazioni dell'account non root www-data . Ma se dai a www-data un modo per eseguire ogni comando che desidera, con i diritti di qualsiasi utente (incluso root ), e senza ulteriori autenticazioni, hai appena perso la funzione di contenimento dei danni.

Per essere onesti, www-data + sudo è leggermente migliore del semplice fatto di eseguire tutto come root , perché il go-to-root deve essere esplicito; quindi, difetti comuni come uno script PHP che scrive file in posizioni improprie sarebbe più difficile da sfruttare. Tuttavia, fare in modo che www-data un membro dei sudoers sembri una pessima idea.

Quando si considera la sicurezza di qualcosa, è necessario presumere che l'utente malintenzionato sia in grado di accedere come utente www-data e di avere una shell. Questo non significa che il tuo attaccante possa davvero ottenere una shell, ma ci possono essere molti modi in cui l'attaccante può eseguire comandi di shell arbitrari; potrebbero essere i risultati di errori di libreria come shellshock o sviste nel codice.

Il modo più sicuro

Il modo migliore per farlo è, come ha detto @AlexeyVesnin, utilizzare un processo specializzato per eseguire il lavoro. Avere questo processo di ascolto su un socket (unix dominio, quindi non è raggiungibile dalla rete), leggere il suo input da detto socket, sanitizzare l'input (!), Fare il lavoro e restituire alcuni risultati alla presa, da dove lo script del server Web legge i risultati. Qualsiasi autorizzazione (l'utente deve immettere una password sul sito Web per poterlo fare) deve essere gestita in tale processo e l'utente di www-data non dovrebbe essere in grado di leggere nessuno dei dati di autorizzazione.

Il modo sudo per lo più sicuro

Nel caso in cui il tuo budget, o le tue abilità, non rendano possibile questo approccio migliore, usare l'approccio sudo non è completamente sbagliato, ma devi limitare le autorizzazioni sudo al minimo necessario. Ad esempio, supponiamo di voler mostrare i dati I / O del disco corrente sul tuo sito web, per i quali devi chiamare iotop :

• crea uno script, in questo esempio /var/www/bin/get-disk-io , che estrae i dati necessari:

  /usr/sbin/iotop -b -n 1 | /usr/bin/head -2

• Non consentire al chiamante dello script di passare alcun parametro, ovvero lo script non deve accedere a $1 , $2 , ..., $* , $@
• Nel caso in cui devi assolutamente utilizzare i parametri, disinfettarli prima nel tuo script. Presta particolare attenzione agli spazi bianchi o ai caratteri insoliti che potrebbero essere nascosti nei parametri.
• Assicurati di indicare il percorso completo per ogni comando in quello script, in modo che gli autori degli attacchi non possano sostituire nessuno di questi comandi con il proprio
• Consenti l'accesso a questo script, e solo questo script , in /etc/sudoers
• Assicurati che env_reset sia nella norma dei valori predefiniti nel file sudoers

Si noti che questo è ancora più sicuro di un programma suid, poiché (a) si può limitare chi può eseguirlo, quindi un utente malintenzionato che ottiene la possibilità di eseguire un programma con un altro utente non sarà in grado di usarlo, (b) non puoi passare parametri arbitrari ad esso, (c) l'ambiente è sanificato da sudo , e (d) puoi fare sudo log quando il comando viene eseguito, quindi hai un audit trail che un programma suid non ti dà.

Il modo suid

Nota: non farlo a meno che tu non sappia cosa stai facendo. Se stai chiedendo o leggendo questa domanda su stackexchange, probabilmente no. Quindi non farlo.

Se imposti il proprietario di un eseguibile a un determinato utente ( chown user /my/executable/file ), quindi imposta il bit suid ( chmod u+s /my/executable/file ), quindi quel programma verrà eseguito con le autorizzazioni di quell'utente ogni volta che viene eseguito. Ad esempio, chown root /bin/cat; chmod u+s /bin/cat eseguirà ogni chiamata di cat con i diritti di root, il che significa che puoi leggere ogni file sul sistema indipendentemente dai suoi diritti di accesso. Non provarlo su un sistema connesso a una rete, nemmeno per 5 minuti per "verificare se funziona" .

• Su molti sistemi unix, questo funziona solo per i programmi compilati, non per gli script che richiedono un interprete
• In alcune configurazioni, ad esempio se si esegue il programma in strace , il bit s non ha alcun effetto
• Nelle configurazioni NFS, root spesso non ha accesso ai file sul server NFS, quindi questo potrebbe anche ridurre ciò che si è in grado di fare.

La modalità Linux suid limitata

Linux ha un sistema di funzionalità, che funziona quasi come suid, ma una granularità molto più fine. Ad esempio, se è necessario un processo per poter utilizzare i numeri di porta inferiori a 1024, nei sistemi unix classici, è necessario eseguire il comando come utente root, spesso a indicare che è necessario eseguire la roba chown/chmod u+s di cui sopra, che consente di utilizzare tali porte numeri, ma garantisce anche l'accesso al filesystem. Linux ti permette di dare la capacità della porta senza tutto ciò che viene fornito con root:

setcap cap_net_bind_service+EP /path/to/my/program

Fai man 7 capabilities per saperne di più. Se consideri seriamente di dare un programma a un programma, pensaci due volte se impostare una capacità non è un'idea migliore.

Ogni momento, senza eccezioni, quando vedi ALL=(ALL) NOPASSWD: ALL nel file /etc/sudoers , qualcuno merita di essere licenziato. Fondamentalmente, hai un secondo utente root.

È sicuro? Diavolo, no. Crea una vulnerabilità? Diavolo sì.

Puoi poter utilizzare sudo per garantire a un utente non root (compresi i dati www) un'esecuzione privilegiata, ma dovrebbe sempre essere il più specifico possibile. Se devi eseguire /usr/bin/my_system_tool +x /var/cache/my_cache come root per qualsiasi motivo, quel comando esatto, inclusi i parametri dovrebbe essere nel file /etc/sudoers .