Nel mio articolo precedente, "I veri amministratori di sistema non sudo", ho discusso dell'orribile uso improprio di sudo da alcune distribuzioni. In questo articolo, che è parzialmente estratto dal Capitolo 11 del mio libro, "Using and Administering Linux, Zero to SysAdmin, Volume 1:Getting started", esploro un paio di casi d'uso validi per sudo .
Caso d'uso 1:Copia file remota
Di recente ho scritto un breve programma Bash per copiare alcuni file MP3 da una chiavetta USB su un host di rete su un altro host di rete. I file vengono copiati in una directory specifica sul server che eseguo per un'organizzazione a cui appartengo, da dove possono essere scaricati e riprodotti.
Il mio programma fa alcune altre cose, come cambiare il nome dei file prima che vengano copiati in modo che vengano automaticamente ordinati per data sulla pagina web. Elimina anche tutti i file sull'unità USB dopo aver verificato che il trasferimento sia avvenuto correttamente. Questo bel programmino ha alcune opzioni come -h per visualizzare la guida, -t per la modalità test e un paio di altri.
Il mio programma, meraviglioso com'è, ha bisogno di essere eseguito come root per poter svolgere le sue funzioni primarie. Sfortunatamente, questa organizzazione ha solo un paio di persone oltre a me che hanno interesse ad amministrare i nostri sistemi audio e informatici, il che mi mette nella posizione di trovare persone semi-tecniche da addestrare per accedere al computer che utilizziamo per eseguire il trasferimento e esegui questo piccolo programma.
Non è che non possa eseguire il programma da solo, ma non sono sempre presente per vari motivi come viaggi e malattie. Anche quando sono presente, come "Lazy SysAdmin", mi piace che gli altri facciano il mio lavoro per me. Quindi scrivo script per automatizzare queste attività e uso sudo per ungere un paio di utenti per eseguire gli script. Molti comandi Linux richiedono che l'utente sia root per poter essere eseguito. Questo protegge il sistema da danni accidentali come quelli causati dalla mia stupidità e danni intenzionali da parte di un utente con intenzioni malevole.
Fai quel sudo che fai così bene
Il sudo programma è uno strumento utile che mi consente come amministratore di sistema con accesso root di delegare la responsabilità di tutte o alcune attività amministrative ad altri utenti del computer come ritengo opportuno. Mi consente di eseguire tale delega senza compromettere la password di root e quindi mantenere un elevato livello di sicurezza sull'host.
Supponiamo, ad esempio, che io abbia concesso a un utente normale, "ruser", l'accesso al mio programma Bash, myprog , che deve essere eseguito come root per poter svolgere parte delle sue funzioni. Innanzitutto, l'utente effettua il login come utente con la propria password. L'utente utilizza quindi il comando seguente per eseguire myprog .
sudo myprog
Il sudo il programma controlla il /etc/sudoers file e verifica che ruser sia autorizzato a eseguire myprog . In tal caso, sudo richiede all'utente di inserire la propria password, non la password di root. Dopo che il utente ha immesso la propria password, il programma viene eseguito. sudo registra anche i fatti dell'accesso a myprog con la data e l'ora di esecuzione del programma, il comando completo e l'utente che lo ha eseguito. Questi dati sono registrati in /var/log/security .
Trovo che avere il registro di ogni comando eseguito da sudo per essere d'aiuto nella formazione. Posso vedere chi ha fatto cosa e se ha effettivamente inserito il comando correttamente.
L'ho fatto per delegare l'autorità di eseguire un singolo programma a me stesso e a un altro utente. Tuttavia, sudo può essere utilizzato per fare molto di più. Può consentire all'amministratore di sistema di delegare l'autorità per la gestione di funzioni di rete o servizi specifici a una singola persona oa un gruppo di utenti fidati. Consente di delegare queste funzioni proteggendo la sicurezza della password di root.
Configurazione del file sudoers
Come amministratore di sistema, posso usare /etc/sudoers file per consentire a utenti o gruppi di utenti di accedere a un singolo comando, a gruppi di comandi definiti oa tutti i comandi. Questa flessibilità è fondamentale sia per la potenza che per la semplicità dell'utilizzo di sudo per delega.
Ho copiato l'intero sudoers file nella Figura 1 dall'host su cui lo sto usando per decostruirlo per te. L'ho trovato molto confuso la prima volta che l'ho incontrato. Si spera che non sarà così oscuro per te quando avremo finito. Mi piace che le distribuzioni basate su Red Hat tendano ad avere file di configurazione predefiniti con molti commenti ed esempi per fornire indicazioni. Questo rende le cose più facili poiché è molto meno necessario cercare su Google.
Non utilizzare il tuo editor standard per modificare i sudoers file. Usa il visudo comando perché è progettato per abilitare eventuali modifiche non appena il file viene salvato e si esce dall'editor. È possibile utilizzare editor oltre a vi allo stesso modo di visudo .
Iniziamo ad analizzare questo file all'inizio con un paio di tipi di alias.
Alias host
La sezione Host Alias viene utilizzata per creare gruppi di host su cui è possibile utilizzare comandi o alias di comando per fornire l'accesso. L'idea di base è che questo singolo file verrà mantenuto per tutti gli host di un'organizzazione e copiato in /etc su ogni host. Alcuni host, come i server, possono quindi essere configurati come un gruppo per consentire ad alcuni utenti di accedere a comandi specifici come la possibilità di avviare e interrompere servizi come HTTPD, DNS, networking, la possibilità di montare filesystem e così via.
Gli indirizzi IP possono essere utilizzati al posto dei nomi host negli alias host.
## Sudoers allows particular users to run various commands as
## the root user, without needing the root password.
##
## Examples are provided at the bottom of the file for collections
## of related commands, which can then be delegated out to particular
## users or groups.
##
## This file must be edited with the 'visudo' command.
## Host Aliases
## Groups of machines. You may prefer to use hostnames (perhaps using
## wildcards for entire domains) or IP addresses instead.
# Host_Alias FILESERVERS = fs1, fs2
# Host_Alias MAILSERVERS = smtp, smtp2
## User Aliases
## These aren't often necessary, as you can use regular groups
## (ie, from files, LDAP, NIS, etc) in this file - just use %groupname
## rather than USERALIAS
# User_Alias ADMINS = jsmith, mikem
User_Alias AUDIO = dboth, user
## Command Aliases
## These are groups of related commands...
## Networking
# Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool
## Installation and management of software
# Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum
## Services
# Cmnd_Alias SERVICES = /sbin/service, /sbin/chkconfig
## Updating the locate database
# Cmnd_Alias LOCATE = /usr/bin/updatedb
## Storage
# Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount, /bin/umount
## Delegating permissions
# Cmnd_Alias DELEGATING = /usr/sbin/visudo, /bin/chown, /bin/chmod, /bin/chgrp
## Processes
# Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/kill, /usr/bin/killall
## Drivers
# Cmnd_Alias DRIVERS = /sbin/modprobe
# Defaults specification
#
# Refuse to run if unable to disable echo on the tty.
#
Defaults !visiblepw
Defaults env_reset
Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
## Next comes the main part: which users can run what software on
## which machines (the sudoers file can be shared between multiple
## systems).
## Syntax:
##
## user MACHINE=COMMANDS
##
## The COMMANDS section may have other options added to it.
##
## Allow root to run any commands anywhere
root ALL=(ALL) ALL
## Allows members of the 'sys' group to run networking, software,
## service management apps and more.
# %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS
## Allows people in group wheel to run all commands
%wheel ALL=(ALL) ALL
## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL
## Allows members of the users group to mount and unmount the
## cdrom as root
# %users ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom
## Allows members of the users group to shutdown this system
# %users localhost=/sbin/shutdown -h now
## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d
################################################################################
# Added by David Both, 11/04/2017 to provide limited access to myprog #
################################################################################
#
AUDIO guest1=/usr/local/bin/myprog Figura 1 :un file sudoers predefinito con le mie modifiche in grassetto.
Alias utente
Il prossimo gruppo di esempi di configurazione sono gli alias utente. Ciò consente a root di ordinare gli utenti in gruppi con alias in modo che a un intero gruppo possa essere fornito l'accesso a determinate funzionalità di root. Per il programmino che ho scritto, ho aggiunto il seguente alias a questa sezione che definisce l'alias AUDIO e assegna due utenti a quell'alias.
User_Alias AUDIO = dboth, ruser
È possibile, come indicato in sudoers file stesso, per usare semplicemente i gruppi Linux definiti in /etc/groups file invece di alias. Se hai già definito un gruppo che soddisfa le tue esigenze, ad esempio "audio", utilizza il nome del gruppo preceduto da un % firmare in questo modo:%audio quando si assegnano comandi disponibili ai gruppi più avanti in sudoers file.
Alias di comando
Più in basso i sudoers file è una sezione con alias di comando. Questi alias sono elenchi di comandi correlati come comandi di rete o comandi necessari per installare aggiornamenti o nuovi pacchetti RPM. Questi alias consentono all'amministratore di sistema di consentire facilmente l'accesso a gruppi di comandi.
In questa sezione sono già impostati numerosi alias che semplificano la delega dell'accesso a tipi specifici di comandi. Non ne abbiamo bisogno per il nostro caso d'uso.
Impostazioni predefinite dell'ambiente
La sezione successiva imposta alcune variabili di ambiente predefinite. L'elemento più interessante in questa sezione è il !visiblepw riga che impedisce sudo dall'esecuzione se l'ambiente utente è impostato per mostrare la password. Questa è una precauzione di sicurezza che non dovrebbe essere ignorata.
Sezione dei comandi
Questa sezione è la parte principale dei sudoers file. Tutto il necessario può essere fatto senza tutti gli alias aggiungendo abbastanza voci qui. Gli alias rendono tutto molto più semplice usando gli alias già definiti per dire a sudo chi può fare cosa su quali host. Gli esempi sono autoesplicativi una volta compresa la sintassi in questa sezione. Diamo quindi un'occhiata alla sintassi che troviamo nella sezione dei comandi. Nella figura 2 abbiamo una voce generica per il nostro utente, ruser.
ruser ALL=(ALL) ALL Figura 2 :una voce generica che dice che Ruser può eseguire qualsiasi programma su qualsiasi host come qualsiasi utente.
Il primo ALL nella riga indica che questa regola si applica a tutti gli host. Il secondo ALL consente al ruser di eseguire comandi come qualsiasi altro utente. Per impostazione predefinita, i comandi vengono eseguiti come utente root ma Ruser può specificare su sudo riga di comando che un programma viene eseguito come qualsiasi altro utente. L'ultimo ALL significa che Ruser può eseguire tutti i comandi senza restrizioni. Questa voce renderebbe Ruser efficacemente nella radice. Non useremo questa voce perché non vogliamo che questo utente abbia tutte queste capacità.
Nota che c'è una voce per root come mostrato nella Figura 3 . Questa voce consente a root di avere accesso completo a tutti i comandi su tutti gli host.
root ALL=(ALL) ALL
Figura 3 :Una voce che dice che toot può eseguire qualsiasi programma su qualsiasi host come qualsiasi utente.
Ma, ovviamente, ho dovuto provarlo, quindi ho commentato la riga in Figura 3 e, come root, ha provato a eseguire chown senza sudo . Ha funzionato, con mia grande sorpresa. Poi ho usato sudo chown e ciò non è riuscito con il messaggio "root non è nel file sudoers. Questo incidente verrà segnalato". Ciò significa che root può eseguire tutto come root, ma niente quando si usa sudo comando. Ciò impedirebbe a root di eseguire comandi come altri utenti tramite sudo comando, ma root ha molti modi per aggirare questa restrizione.
La voce in Figura 4 è quello che ho aggiunto per controllare l'accesso a myprog . Specifica gli utenti che sono elencati nel gruppo AUDIO, come definito nella parte superiore di sudoers file, avere accesso a un solo programma, myprog , su un host, guest1.
AUDIO guest1=/usr/local/bin/myprog
Figura 4 :Questa è la voce che ho aggiunto per consentire agli utenti che fanno parte del gruppo AUDIO di accedere a myprog sull'host, guest1.
Nota che la sintassi della riga nella Figura 4 specifica solo l'host su cui deve essere consentito questo accesso e il programma. Non specifica che l'utente può eseguire il programma come qualsiasi altro utente.
Password ignorate
Figura 5 illustra l'utilizzo di NOPASSWORD per consentire agli utenti specificati nel gruppo AUDIO di eseguire myprog senza la necessità di inserire le proprie password.
AUDIO guest1=NOPASSWORD : /usr/local/bin/myprog
Figura 5 :Questa voce ipotetica consentirebbe agli utenti che fanno parte del gruppo AUDIO di accedere a myprog senza la necessità di inserire le proprie password.
Non l'ho fatto per il mio programma perché credo che gli utenti con sudo l'accesso deve fermarsi e pensare a cosa stanno facendo e questo può aiutare un po' in questo. Ho appena usato la voce per il mio programmino come esempio.
Ruota
La specifica della ruota nella sezione comandi di sudoers come mostrato nella Figura 6 consente a tutti gli utenti nel gruppo di ruote di eseguire tutti i comandi su qualsiasi host. Il gruppo di ruote è definito in /etc/group il file e gli utenti devono essere aggiunti al gruppo per farlo funzionare. Il % il segno che precede il nome del gruppo significa che sudo dovrebbe cercare quel gruppo in /etc/group file.
%wheel ALL = (ALL) ALL
Figura 6 :Questa voce dice che tutti gli utenti che sono membri del gruppo ruota come definito in /etc/group file può eseguire tutti i comandi su qualsiasi host.
Questo è un buon modo per delegare l'accesso root completo a più utenti senza fornire la password di root. La semplice aggiunta di un utente al gruppo di ruote consente loro di accedere a tutti i poteri di root. Fornisce inoltre un mezzo per monitorare le loro attività tramite le voci di registro create da sudo . Alcune distribuzioni come Ubuntu aggiungono gli ID degli utenti al gruppo di ruote in /etc/group che consente loro di utilizzare il sudo comando per utilizzare tutti i comandi privilegiati.
Caso d'uso 2:la presentazione
Di solito pensiamo alle presentazioni in termini di diapositive slick create da LibreOffice Impress o PowerPoint, transizioni animate e grafica, ma non è necessario che sia così. Il 3 marzo di quest'anno ho presentato una sessione estesa all'Open Source 101 in Columbia South Carolina, intitolata "Using and Configuration Bash".
Ora, se stai partecipando a una lunga sessione sull'uso di Bash, perché vorresti vedere molte diapositive fantasiose? Personalmente, voglio vedere Bash in uso. Così ho creato uno script Bash che è diventato la mia presentazione. Non sono un dattilografo veloce o preciso, quindi questo mi ha anche permesso di preprogrammare tutti i comandi che volevo dimostrare nello script Bash, quindi avrei solo bisogno di premere il Enter per passare alla diapositiva successiva contenente testo o per emettere un comando. Questo ha funzionato molto bene per me e anche ai partecipanti è piaciuto perché era un ottimo caso d'uso per gli script Bash.
Questo è rilevante perché uno e solo uno dei comandi in questo script della shell Bash di 1500 righe richiedeva il privilegio di root. Sarebbe incredibilmente insicuro accedere come root ed eseguire l'intero programma. E se si verificasse un errore che cancellava o alterava alcuni file importanti a livello di sistema? Come amministratore di sistema e programmatore Bash, non sono perfetto e si verificano errori.
Quindi la risposta è stata eseguire il programma come utente "studente" e utilizzare sudo comando come prefisso dell'unico comando che richiedeva l'accesso privilegiato. Anche nel bel mezzo della mia presentazione, digitare la password per l'utente studente è stato facile. L'ho usato anche nella mia presentazione come esempio di un uso appropriato di sudo .
L'impostazione per questo caso d'uso è la stessa del caso precedente, solo con nomi utente e nomi di comando diversi.
Considerazioni finali
Ho usato sudo in questi casi per un obiettivo molto limitato:fornire a uno o due utenti l'accesso a un unico comando. L'ho realizzato con due righe se ignori i miei commenti. Delegare l'autorità per eseguire attività specifiche a utenti che non hanno accesso come root è semplice e può farti risparmiare molto tempo come amministratore di sistema. Può anche migliorare significativamente la sicurezza fornendo l'accesso a comandi specifici solo quando necessario.
Il sudo comando genera anche voci di registro che possono aiutare a rilevare i problemi. I sudoers file offre una pletora di funzionalità e opzioni per la configurazione. Controlla il man file per sudo e sudoers per i dettagli sporchi e sporchi.
[ Scarica ora:una guida per l'amministratore di sistema allo scripting Bash. ]