Vorrei creare un nuovo utente e dargli l'accesso sudo. Per essere precisi, voglio che usi sudo vim e modifica httpd.conf. L'ho scritto in sudoers:

user ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf

Tuttavia, ho sentito che questo potrebbe essere rischioso. Perché questo è problematico? Quanto è grave il problema?

Risposta accettata:

Sebbene tu limiti gli argomenti della riga di comando, non c'è nulla che impedisca all'utente di usare vim per aprire, modificare e sovrascrivere qualsiasi file casuale una volta eseguito come root.

L'utente può eseguire sudo vim /etc/httpd/conf/httpd.conf e poi

• cancella tutto quel testo dal buffer di modifica
• quindi per comodità procurati un file esistente (anche se non è nemmeno richiesto):ad esempio la configurazione di sudo
  :r /etc/sudoers NOTA:a meno che non sia limitato da SELinux, l'utente può leggere qualsiasi archivia in questo modo!
• concede più privilegi sudo user ALL=(ALL) NOPASSWD: ALL
• sovrascrivi la vecchia configurazione :w /etc/sudoers

Posso immaginare dozzine di modi simili in cui il tuo utente può ora accedere, modificare o distruggere il tuo sistema.

Non avrai nemmeno un audit trail quali file sono stati modificati in questo modo poiché lo vedrai solo modificare la tua configurazione di Apache nei messaggi di registro sudo. Questo è un rischio per la sicurezza nel concedere sudo privilegi a qualsiasi editor.

Questo è più o meno lo stesso motivo per cui si concedono diritti a livello di root sudo a comandi come tar e unzip è spesso insicuro, nulla ti impedisce di includere nell'archivio le sostituzioni dei file binari di sistema o dei file di configurazione del sistema.

Un secondo rischio, come hanno sottolineato molti altri commentatori, è che vim consente fughe di shell , dove puoi avviare una sub-shell dall'interno di vim che ti consente di eseguire qualsiasi comando arbitrario . Dall'interno della tua sessione sudo vim, quelli verranno eseguiti come root, ad esempio l'escape della shell:

• :!/bin/bash ti darà una shell di root interattiva
• :!/bin/rm -rf / farà belle storie al pub.

Cosa fare invece?

Puoi ancora usare sudo per consentire agli utenti di modificare i file di cui non sono proprietari in modo sicuro.

Nella tua configurazione sudoers puoi impostare uno speciale comando riservato sudoedit seguito dal percorso completo (carattere jolly) dei file che un utente può modificare:

user ALL=(ALL) sudoedit /etc/httpd/conf/httpd.conf /etc/httpd/conf.d/*.conf

L'utente può quindi utilizzare il -e cambia nella loro riga di comando sudo o usa il sudoedit comando:

sudo -e /etc/httpd/conf/httpd.conf
sudoedit /etc/httpd/conf/httpd.conf

Come spiegato nella pagina man:

Il -e (edit) opzione indica che, invece di eseguire un comando, l'utente desidera modificare uno o più file. Al posto di un comando, la stringa "sudoedit" viene utilizzata durante la consultazione della politica di sicurezza.
Se l'utente è autorizzato dalla politica, vengono eseguiti i seguenti passaggi:

• Si eseguono copie temporanee dei file da modificare con il proprietario impostato sull'utente che effettua il richiamo.
• L'editor specificato dal criterio viene eseguito per modificare i file temporanei. La politica sudoers utilizza le variabili di ambiente SUDO_EDITOR, VISUAL ed EDITOR (in quest'ordine). Se nessuno di SUDO_EDITOR, VISUAL o EDITOR è impostato, il primo programma elencato nell'editor sudoers (5) viene utilizzata l'opzione.
• Se sono stati modificati, i file temporanei vengono copiati nella loro posizione originale e le versioni temporanee vengono rimosse.
  Se il file specificato non esiste, verrà creato.
  Nota che, a differenza di la maggior parte dei comandi eseguiti da sudo, l'editor viene eseguito con l'ambiente dell'utente che esegue il richiamo non modificato. Se, per qualche motivo, sudo non è in grado di aggiornare un file con la sua versione modificata, l'utente riceverà un avviso e la copia modificata rimarrà in un file temporaneo.

I sudoers il manuale ha anche un'intera sezione su come può offrire una protezione limitata contro le fughe di proiettili con il RESRICT e NOEXEC opzioni.

restrict Evitare di concedere agli utenti l'accesso a comandi che consentono all'utente di eseguire comandi arbitrari. Molti editor hanno una modalità limitata in cui gli escape della shell sono disabilitati, sebbene sudoedit sia una soluzione migliore per eseguire gli editor tramite sudo. A causa del gran numero di programmi che offrono escape della shell, limitare gli utenti all'insieme di programmi che non lo fanno è spesso impraticabile.

e

noexec
Molti sistemi che supportano le librerie condivise hanno la capacità di sovrascrivere le funzioni di libreria predefinite puntando una variabile di ambiente (di solito LD_PRELOAD) a una libreria condivisa alternativa. Su tali sistemi, la funzionalità noexec di sudo può essere utilizzata per impedire a un programma eseguito da sudo di eseguire altri programmi. Nota, ... ...
Per abilitare noexec per un comando, usa il NOEXEC tag come documentato nella sezione Specifiche utente sopra. Ecco di nuovo quell'esempio:
aaron shanty = NOEXEC: /usr/bin/more, /usr/bin/vi
Ciò consente all'utente aaron di eseguire /usr/bin/more e /usr/bin/vi con noexec abilitato. Ciò impedirà a questi due comandi di eseguire altri comandi (come una shell).