Utilizzando CmndAlias ALL non sarà mai al sicuro
Ci sono 1000 modi per eseguire service network restart senza fare sudo service network restart . Ecco un esempio di cosa potrebbe provare un utente cattivo:
$ echo "service network restart" > /tmp/hax
$ chmod a+x /tmp/hax
$ sudo /tmp/hax
Se fornisci agli utenti ALL command alias, e quindi provare a creare una lista nera, saranno sempre in grado di trovare un modo per aggirarlo. Blacklist bash e useranno python. Blacklist python e useranno Perl. Blacklist Perl e useranno PHP. Nessuno lo vuole!
Se davvero non vuoi che qualcuno faccia qualcosa, dovresti fare come dice Thomas e creare una lista bianca di cose che sono permesso di fare.
Impostazione di una whitelist con un'eccezione
Un esempio di una piccola lista bianca con un'esclusione è disponibile nella parte inferiore di man sudoers :
pete HPPA = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd root
The user pete is allowed to change anyone's password except for root on the HPPA
machines. Note that this assumes passwd(1) does not take multiple user names
on the command line.
(In effetti questo esempio dalla manpage non è sicuro e può essere sfruttato per cambiare la password di root! Vedi i commenti sotto per come.)
Possiamo provare ad adattarlo al tuo caso, per offrire tutti i service comandi al gruppo staff, ma exclude il service network comandi che ti riguardano:
%staff ALL = /usr/sbin/service *, \
! /usr/sbin/service *network*, \
! /usr/sbin/service *NetworkManager*
(Il ALL in quella posizione si riferisce all'Host_Alias, non al Cmnd_Alias - confusione non è vero?)
L'utente non sarà in grado di eseguire sudo bash o sudo tee o sudo wget o sudo /path/to/malicious_script . Puoi autorizzare più comandi di amministrazione per i tuoi utenti se stai attento. Sii specifico!
Nota:ho aggiunto il * prima della parola network sopra, nel caso in cui venga aggiunto un flag innocuo al service strumento in futuro. Immaginiamo un --verbose flag è stato aggiunto in futuro, gli utenti saranno in grado di eseguire quanto segue:
$ sudo service --verbose network restart
Quindi abbiamo bisogno del * per consumare eventuali flag prima del nome del servizio. L'unico svantaggio è che questo potrebbe bloccare altri servizi che in realtà non ti dispiace che gli utenti eseguano, ad es. un servizio chiamato safe-network o network-monitor verrebbe anche rifiutato.
Consenti agli utenti di modificare un file utilizzando le autorizzazioni di gruppo
Di seguito puoi trovare vari tentativi usando rnano attraverso sudo per consentire agli utenti di modificare uno o più file. Ma in realtà sono più complesse e più pericolose di quanto dovrebbero essere.
Una soluzione molto più semplice e sicura consiste nel modificare le autorizzazioni di gruppo sui file specifici per i quali si desidera aprire i diritti di modifica. Ecco un paio di esempi:
### Give steve the ability to edit his nginx config:
$ chgrp steve /etc/nginx/sites-available/steves_dodgy_project
$ chmod g+rw /etc/nginx/sites-available/steves_dodgy_project
### Let all members of the staff group edit the group_website config:
$ chgrp staff /etc/nginx/sites-available/group_website
$ chmod g+rw /etc/nginx/sites-available/group_website
Se hai bisogno di un controllo più capillare (ad esempio:accesso solo per 3 utenti, ma non per tutti i membri dello staff) puoi creare un nuovo gruppo utilizzando il addgroup comando e aggiungervi solo pochi utenti.
Consenti agli utenti di modificare un file tramite sudo
Il resto di questa risposta è diventato un'indagine su quanto sia facile lasciare buchi nel tuo sudo configurazione quando cerchi di offrire flessibilità ai tuoi utenti. Non consiglierei di eseguire nessuna delle seguenti operazioni!
Se vuoi concedere ai tuoi utenti l'accesso per modificare un file specifico, puoi provare a utilizzare rnano :
%staff ALL = /bin/rnano /etc/nginx/sites-available/host
rnano permetterà loro di modificare solo il file specificato. Questo è importante per impedire a un utente malintenzionato di modificare un servizio nuovo arrivato diverso (ad esempio /etc/init.d/urandom ) e aggiungendovi una riga che eseguirà service network restart .
Sfortunatamente non ho trovato un modo per limitare rvim sufficientemente (l'utente può ancora aprire qualsiasi file utilizzando :e ), quindi siamo bloccati con nano .
Sfortunatamente consentire agli utenti di modificare più file è molto più difficile...
Consenti agli utenti di modificare più file (molto più difficile di quanto dovrebbe essere)
1. Approcci non sicuri
Attenti ai caratteri jolly! Se offri troppa flessibilità (o qualsiasi flessibilità), può essere sfruttata:
%staff ALL = /bin/rnano /etc/nginx/sites-available/* # UNSAFE!
In questo caso, un utente malintenzionato sarebbe in grado di modificare qualsiasi altro script di servizio upstart e quindi eseguirlo:
$ sudo rnano /etc/nginx/sites-available/../../../any/file/on/the/system
(Sudo in realtà impedisce . e .. espansione sul comando, ma sfortunatamente non sugli argomenti.)
Speravo che qualcosa di simile potesse funzionare, ma è ancora insicuro:
%staff ALL = /bin/rnano /etc/nginx/sites-available/[A-Za-z0-9_-]* # UNSAFE!
Da sudo attualmente offre solo glob modelli, che * corrisponderà a qualsiasi cosa - non è una regexp!
(Modifica:ho considerato se potresti farla franca nella tua situazione, perché non ci sono sottocartelle sotto sites-available . Abbiamo richiesto la corrispondenza di un carattere dopo la cartella e /.. dovrebbe fallire dopo un nome file. Tuttavia questa non è una soluzione praticabile, perché rnano accetta più argomentazioni. E comunque in generale questo sarebbe ancora non sicuro su una cartella che aveva sottocartelle!)
Anche se non abbiamo sottocartelle ed escludiamo qualsiasi riga contenente /../ , la regola che offre un * glob potrebbe ancora essere sfruttato, perché rnano accetta più argomenti (ciclandoli su <C-X> , e lo spazio è felicemente accettato dal * globo.
$ rnano /etc/nginx/sites-available/legal_file /then/any/file/on/the/system
2. Spingere la busta (anche in definitiva pericoloso)
Quindi cosa succede se rifiutiamo qualsiasi riga contenente spazi o se tentiamo di raggiungere /.. ? Quindi una soluzione praticabile finale potrebbe essere questa:
# I tried hard to make this safe, but in the end I failed again.
# Please don't use this unless you are really smart or really stupid.
%staff ALL = /bin/rnano /etc/nginx/sites-available/*, \
! /bin/rnano */..*, \
! /bin/rnano /etc/nginx/sites-available/, \
! /bin/rnano */., \
! /bin/rnano * *
# CONCLUSION: It is still NOT SAFE if there are any subfolders, due to
# the bug in rnano described below.
Accettiamo qualsiasi cosa "sotto" la cartella, ma rifiutiamo anche qualsiasi chiamata a rnano se /.. o /. o vengono passati o se la cartella è indirizzata direttamente. (Tecnicamente il /. l'esclusione rende il /.. esclusione ridondante, ma ho lasciato entrambi per chiarezza.)
Ho trovato la cartella e il /. le esclusioni erano necessarie perché altrimenti l'utente avrebbe potuto scegliere come target la cartella stessa. Ora potresti pensare a rnano si bloccherebbe se puntato su una cartella, ma ti sbaglieresti. In realtà la mia versione (2.2.6-1ubuntu1) si avvia con un lieve avviso e un file vuoto, quindi su <C-X> mi chiede di inserire qualsiasi nome di file che mi piace salvare, aprendo un nuovo vettore di attacco! Beh, almeno si è rifiutato di sovrascrivere un file esistente (nell'unico test che ho fatto). Ad ogni modo, poiché non c'è modo di inserire nella blacklist le sottocartelle con sudo, dobbiamo concludere che anche questo approccio non è sicuro. Scusate gli utenti!
Questa scoperta mi ha fatto dubitare della completezza di nano la modalità "ristretta". Dicono che una catena è forte quanto il suo anello più debole. Comincio a sentire la combinazione di sudo lista nera black-magic e rnano potrebbe non essere più sicuro di una catena di margherite.
3. Approcci sicuri ma limitati
I glob sono molto limitati:non ci consentono di abbinare più volte una classe di personaggi. Potresti offri più modifiche ai file, se tutti i tuoi nomi di file hanno la stessa lunghezza (in questo caso host seguito da una singola cifra):
%staff ALL = /bin/rnano /etc/nginx/sites-available/host[0-9] # SAFE
Ma se vuoi dare all'utente l'accesso per modificare vari file, potresti dover specificare esplicitamente ogni singolo file:
%staff ALL = /bin/rnano /etc/nginx/sites-available/hothost \
/bin/rnano /etc/nginx/sites-available/coldhost \ # SAFE
/bin/rnano /etc/nginx/sites-available/wethost \
/bin/rnano /etc/nginx/sites-available/steves_dodgy_project
Non lasciarti tentare per usare un * in qualsiasi punto. Vedere le sezioni 1. e 2. sopra per il perché! Ricorda:un piccolo errore può compromettere l'intero account di superutente e l'intero sistema.
4. Scrivi il tuo correttore di argomenti (la sicurezza è ora una tua responsabilità)
Spero che aggiungano il supporto regexp a sudo nel futuro; potrebbe risolvere molti problemi se usato correttamente. Ma potremmo anche aver bisogno della possibilità di controllare le proprietà degli argomenti (per consentire solo file, solo cartelle o solo determinati flag).
Ma c'è un'alternativa per creare flessibilità in sudo. Passa il dollaro:
%staff ALL = /root/bin/staffedit *
Quindi scrivi il tuo staffedit script o eseguibile per verificare se gli argomenti passati dall'utente sono legali ed eseguire la richiesta solo se lo sono.
Innanzitutto, apri il file sudoers con sudo visudo . Aggiunta di user ALL=!/usr/sbin/service IIRC non consentirà il service comando per l'utente user .
Fonti:http://nixcraft.com/showthread.php/15132-Sudo-Exclude-Commands-And-Disable-sudo-su-Bash-Shell
Ho trovato la soluzione.
Ho aperto il terminale e sono passato all'utente root con su - poi ho digitato visudo da modificare.
poi alla fine ho scritto righe come
user ALL=!/etc/init.d/NetworkManager restart
user ALL=!/etc/init.d/network restart
Poi ho anche salvato, chiuso e riavviato.
Ora se sto digitando come service network restart o service NetworkManager restart allora non me lo permette e dà un errore come
Sorry user is not allowed to execute '/sbin/service NetowkrManager restart' as root on localhost.localdomain
e allo stesso modo per service network restart comando anche.