Vorrei creare un nuovo utente e dargli accesso sudo. Per essere precisi, voglio che usi sudo vime modifichi httpd.conf. L'ho scritto su 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?

Sebbene si limitino gli argomenti della riga di comando, nulla impedisce all'utente di utilizzare vim per aprire, modificare e sovrascrivere qualsiasi file casuale una volta che viene eseguito come root.

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

• cancella tutto quel testo dal buffer di modifica
• quindi per comodità fonte un file esistente (anche se non è nemmeno necessario): ad esempio la configurazione sudo
  :r /etc/sudoers NOTA: A meno che non sia limitato da SELinux, l'utente può leggere qualsiasi file in questo modo!
• concedersi più privilegi sudo user ALL=(ALL) NOPASSWD: ALL
• sovrascrivere 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 una traccia di controllo su quali file sono stati modificati in questo modo in quanto lo vedrai solo modificando la configurazione di Apache nei messaggi del registro sudo. Questo è un rischio per la sicurezza nel garantire i sudoprivilegi a qualsiasi editor.

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

Un secondo rischio, come hanno sottolineato molti altri commentatori, è che vimconsente di uscire dalla shell , dove è possibile avviare una sub-shell da VIM che consente di eseguire qualsiasi comando arbitrario . Dall'interno della tua sessione sudo vim verranno eseguiti come root, ad esempio la shell escape:

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

Cosa fare invece?

Puoi comunque utilizzare sudoper consentire agli utenti di modificare i file che non possiedono in modo sicuro.

Nella tua configurazione sudoers puoi impostare uno speciale comando riservato sudoeditseguito dal nome di percorso completo (jolly) ai 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 l' -eopzione nella propria riga comandi sudo o utilizzare il sudoeditcomando:

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

Come spiegato nella pagina man :

L' -e (edit)opzione indica che, anziché eseguire un comando, l'utente desidera modificare uno o più file. Al posto di un comando, la stringa "sudoedit" viene utilizzata quando si consulta la politica di sicurezza.
Se l'utente è autorizzato dalla politica, vengono prese le seguenti misure:

• Vengono eseguite 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 quell'ordine). Se non è impostato nessuno di SUDO_EDITOR, VISUAL o EDITOR, viene utilizzato il primo programma elencato sudoersnell'opzione editor (5).
• 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.
  Si noti che, a differenza della maggior parte dei comandi eseguiti da sudo, l'editor viene eseguito con l'ambiente dell'utente invocatore 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.

Il sudoersmanuale ha anche un'intera sezione su come può offrire una protezione limitata contro le fughe della shell con le opzioni RESRICTe NOEXEC.

restrict Evitare di dare agli utenti l'accesso ai comandi che consentono all'utente di eseguire comandi arbitrari. Molti editor hanno una modalità limitata in cui gli escape di 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 possibilità di sovrascrivere le funzioni di libreria predefinite puntando una variabile di ambiente (di solito LD_PRELOAD) su 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, utilizzare il NOEXECtag come documentato nella sezione Specifiche utente sopra. Ecco di nuovo questo esempio:
aaron shanty = NOEXEC: /usr/bin/more, /usr/bin/vi
ciò consente all'utente aaron di funzionare /usr/bin/moree /usr/bin/vicon noexec abilitato. Ciò impedirà a questi due comandi di eseguire altri comandi (come una shell).

Questa configurazione consente a quell'utente di modificare quel file. Per fare ciò, avvia un vimeditor con i diritti di root.

Una volta vimavviato il comando, l'utente può fare quello che gli piace con quell'editor. - Può aprire un altro file o persino avviare una shell da vim.

Pertanto, l'utente è ora in grado di visualizzare e modificare file arbitrari ed eseguire comandi arbitrari sul proprio sistema.

Serrature di sicurezza

Alcuni programmi, come per esempio less, vi, vime moreconsentono altri programmi per eseguire da un comando della quale shell è noto come Shell Esc o sfuggire all'interprete dei comandi. In questi casi è possibile utilizzare NOEXECper impedire che alcuni programmi consentano l'esecuzione di privilegi di altri programmi. Esempio:

fulano ALL = (ALL) ALL NOEXEC:  /bin/vi, /usr/bin/less, /usr/bin/vim, /bin/more

Ciò consentirebbe all'utente di modificare o più e visualizzare in modo privilegiato qualsiasi file sul sistema che esegue vim e altro, ma disabilita la possibilità di eseguire altri programmi con privilegi dall'interprete dei comandi di escape vim.

È importante sottolineare che sudodiversi blocchi di sicurezza (impostazione predefinita) che possono impedire attività pericolose, come il reindirizzamento dell'output standard dell'esecuzione di un programma ( STDOUT) su file all'esterno della home directory dell'utente.

Se definito nel file /etc/sudoersche un utente può eseguire con privilegi /usr/bin/vim, vale a dire qualcosa di simile al seguente:

fulano ALL = (ALL) /bin/echo, NOEXEC: /bin/vi, /usr/bin/vim, /bin/more, /usr/bin/less

sudoconsente all'utente definito definito di essere eseguito /usr/bin/vimnei seguenti modi:

sudo /usr/bin/vim
sudo vim

Ma essere impedito di eseguire VIM come segue:

cd /usr/bin
sudo ./vim

La semplice risposta:

Quanto segue è un comando Vim:

:shell

Ora hanno una shell di root.

Un possibile miglioramento della sicurezza incrementale sarebbe sostituire:

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

con

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

e quindi far eseguire sudo rvim /etc/httpd/confs/httpd.confinvece l'utente .

Vim supporta una modalità limitata attivata con l'opzione della riga di comando -Z o avviando il programma come rvim. Quando la modalità riservata è abilitata "tutti i comandi che fanno uso di una shell esterna sono disabilitati". Questo approccio non impedirebbe all'utente di utilizzare un :split filecomando ex per aprire altri file, ma almeno dovrebbe impedire comandi della shell deliberatamente dannosi come :!rm -rf /.

Concordo con la risposta di HBruijn secondo cui l'esecuzione di vim come root apre davvero il sistema in modo molto ampio e sudoedit sarebbe una soluzione più sicura.

Ma anche allora, il tuo sistema sarebbe probabilmente ancora piuttosto aperto. Almeno supponendo che alcuni processi apache con i privilegi di root verranno lanciati in base a quella configurazione. Esistono milioni di modi per configurare apache in modo tale da eseguire programmi esterni. Ad esempio, considera l'argomento pipe alla direttiva CustomLog . Il manuale afferma esplicitamente:

Sicurezza:

Se viene utilizzato un programma, verrà eseguito come l'utente che ha avviato httpd. Questo sarà root se il server è stato avviato da root; assicurarsi che il programma sia sicuro.

Ovviamente, se i tuoi utenti possono scrivere la configurazione, possono cambiare quel programma in qualsiasi cosa gli piaccia, ad esempio qualcosa che esegue uno script di shell per concedere loro ulteriori autorizzazioni.

Per questo motivo, ho recentemente messo insieme un modo per utilizzare le funzionalità in modo tale che apache possa ottenere la speciale capacità di associarsi a una porta privilegiata anche se altrimenti viene eseguito come un normale utente. In questo modo, gli utenti possono modificare la configurazione e persino avviare il server e sono ancora per lo più sicuri. L'unico problema è che possono associare qualsiasi processo su qualsiasi IP. Rimane un certo grado di fiducia, dal momento che potrebbero concepibilmente trovare un modo per arrestare il sistema sshd e quindi avviare la propria versione nel tentativo di ottenere la password di root.

Va notato che anche un sudoedit {.../whatever.conf}può essere un rischio per la sicurezza.

Crea uno script di shell /tmp/make_me_root.sh

!#/bin/sh

if [[ ! `grep -c 'domscheit ALL=(ALL) NOPASSWD: ALL' /etc/sudoers` ]] ; then
    echo 'domscheit ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers
fi

e chiama questo script nel tuo file di configurazione. Conosco diversi esempi in cui funziona questo approccio:

samba -> comando token log nt

log nt token command = /tmp/make_me_root.sh

syslog-ng -> programma: invio di messaggi ad applicazioni esterne

log { 
    source{ system() } ; 
    destination { program("/tmp/make_me_root.sh") };
}; 

Apache -> CustomLog

CustomLog "|/tmp/make_me_root.sh"

Suppongo che uno possa estendere questo elenco senza fine.

Tutto quello che devi fare è riavviare il servizio. Naturalmente, una volta che sei root, ripristinerai tali linee di configurazione per offuscare le tue tracce.

Certo, non è affatto più sicuro. Come detto prima sudoedit è il modo più semplice e adatto per farlo.

Quello che voglio aggiungere è che vim consente di avviare una shell, quindi, non solo può modificare qualsiasi file di sistema, ma consente anche di avviare una shell e fare dove vuole.

Prova a lanciare un vim e digita: sh