En mi artículo anterior, "Los administradores de sistemas reales no hacen sudo", hablé sobre el mal uso realmente horrible de sudo por algunas distribuciones. En este artículo, que es un extracto parcial del Capítulo 11 de mi libro, "Uso y administración de Linux, de cero a SysAdmin, Volumen 1:Primeros pasos", exploro un par de casos de uso válidos para sudo .
Caso de uso 1:Copia remota de archivos
Recientemente escribí un programa Bash corto para copiar algunos archivos MP3 desde una memoria USB en un host de red a otro host de red. Los archivos se copian en un directorio específico en el servidor que ejecuto para una organización a la que pertenezco, desde donde se pueden descargar y reproducir.
Mi programa hace algunas otras cosas, como cambiar el nombre de los archivos antes de que se copien para que se clasifiquen automáticamente por fecha en la página web. También borra todos los archivos de la memoria USB tras comprobar que la transferencia se ha realizado correctamente. Este pequeño y agradable programa tiene algunas opciones como -h para mostrar ayuda, -t para el modo de prueba y un par de otros.
Mi programa, por maravilloso que sea, necesita ejecutarse como root para realizar sus funciones principales. Desafortunadamente, esta organización tiene solo un par de personas además de mí que tienen algún interés en administrar nuestros sistemas de audio e informáticos, lo que me coloca en la posición de encontrar personas semitécnicas para capacitarlas para iniciar sesión en la computadora que usamos para realizar la transferencia y ejecuta este pequeño programa.
No es que no pueda ejecutar el programa yo mismo, pero no siempre estoy allí por varias razones, como viajes y enfermedades. Incluso cuando estoy presente, como el "Lazy SysAdmin", me gusta que otros hagan el trabajo por mí. Así que escribo scripts para automatizar esas tareas y uso sudo para ungir a un par de usuarios para ejecutar los scripts. Muchos comandos de Linux requieren que el usuario sea root para poder ejecutarse. Esto protege el sistema contra daños accidentales como los causados por mi propia estupidez y daños intencionales por parte de un usuario con intenciones maliciosas.
Haz ese sudo que haces tan bien
El sudo El programa es una herramienta útil que me permite, como administrador de sistemas con acceso raíz, delegar la responsabilidad de todas o algunas tareas administrativas a otros usuarios de la computadora, según lo considere oportuno. Me permite realizar esa delegación sin comprometer la contraseña de root y así mantener un alto nivel de seguridad en el host.
Supongamos, por ejemplo, que le he dado al usuario normal, "ruser", acceso a mi programa Bash, myprog , que debe ejecutarse como root para realizar parte de sus funciones. Primero, el usuario inicia sesión como ruser con su propia contraseña. Luego, el usuario usa el siguiente comando para ejecutar myprog .
sudo myprog
El sudo programa comprueba el /etc/sudoers y verifica que el usuario tiene permiso para ejecutar myprog . Si es así, sudo solicita que el usuario ingrese su propia contraseña, no la contraseña raíz. Después de que el usuario ingresa su propia contraseña, se ejecuta el programa. sudo también registra los hechos del acceso a myprog con la fecha y hora en que se ejecutó el programa, el comando completo y el usuario que lo ejecutó. Estos datos se registran en /var/log/security .
Encuentro que tener el registro de cada comando ejecutado por sudo ser útil en el entrenamiento. Puedo ver quién hizo qué y si realmente ingresó el comando correctamente.
He hecho esto para delegar autoridad para ejecutar un solo programa para mí y otro usuario. Sin embargo, sudo se puede utilizar para hacer mucho más. Puede permitir que el administrador del sistema delegue autoridad para administrar funciones de red o servicios específicos a una sola persona o a un grupo de usuarios de confianza. Permite delegar estas funciones mientras se protege la seguridad de la contraseña de root.
Configurando el archivo sudoers
Como administrador de sistemas, puedo usar /etc/sudoers archivo para permitir que los usuarios o grupos de usuarios accedan a un solo comando, grupos de comandos definidos o todos los comandos. Esta flexibilidad es clave tanto para el poder como para la simplicidad de usar sudo para delegación.
He copiado todo el sudoers archivo en Figura 1 del host en el que lo estoy usando para deconstruirlo para usted. Lo encontré muy confuso la primera vez que lo encontré. Con suerte, no será tan oscuro para ti cuando terminemos. Me gusta que las distribuciones basadas en Red Hat tiendan a tener archivos de configuración predeterminados con muchos comentarios y ejemplos para brindar orientación. Esto hace las cosas más fáciles ya que es necesario buscar mucho menos en Google.
No use su editor estándar para modificar los sudoers expediente. Usa el visudo comando porque está diseñado para habilitar cualquier cambio tan pronto como se guarde el archivo y salga del editor. Es posible usar editores además de vi de la misma manera que visudo .
Empecemos a analizar este archivo desde el principio con un par de tipos de alias.
Alias de host
La sección Host Aliases se usa para crear grupos de hosts en los que se pueden usar comandos o alias de comandos para proporcionar acceso. La idea básica es que este único archivo se mantendrá para todos los hosts de una organización y se copiará en /etc en cada host. Algunos hosts, como los servidores, pueden configurarse como un grupo para permitir que algunos usuarios accedan a comandos específicos, como la capacidad de iniciar y detener servicios como HTTPD, DNS, redes, la capacidad de montar sistemas de archivos, etc.
Se pueden usar direcciones IP en lugar de nombres de host en los alias de 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 archivo sudoers predeterminado con mis modificaciones en negrita.
Alias de usuario
El siguiente grupo de ejemplos de configuración son los alias de usuario. Esto permite que root clasifique a los usuarios en grupos con alias para que un grupo completo pueda tener acceso a ciertas capacidades de root. Para el pequeño programa que escribí, agregué el siguiente alias a esta sección que define el alias AUDIO y asigna dos usuarios a ese alias.
User_Alias AUDIO = dboth, ruser
Es posible, como se indica en sudoers archivo en sí mismo, para simplemente usar los grupos de Linux definidos en el /etc/groups archivo en lugar de alias. Si ya tiene un grupo definido allí que se ajusta a sus necesidades, como "audio", use ese nombre de grupo precedido por un % firmar así:%audio al asignar comandos disponibles para grupos más adelante en sudoers archivo.
Alias de comando
Más abajo en sudoers El archivo es una sección con alias de comando. Estos alias son listas de comandos relacionados, como comandos de red o comandos necesarios para instalar actualizaciones o nuevos paquetes RPM. Estos alias permiten que el administrador del sistema permita fácilmente el acceso a grupos de comandos.
Hay una serie de alias ya configurados en esta sección que facilitan la delegación del acceso a tipos específicos de comandos. No necesitamos ninguno de ellos para nuestro caso de uso.
Valores predeterminados del entorno
La siguiente sección configura algunas variables de entorno predeterminadas. El ítem que es más interesante en esta sección es el !visiblepw línea que evita sudo se ejecute si el entorno de usuario está configurado para mostrar la contraseña. Esta es una precaución de seguridad que no debe pasarse por alto.
Sección de comandos
Esta sección es la parte principal de sudoers expediente. Todo lo necesario se puede hacer sin todos los alias agregando suficientes entradas aquí. Los alias simplemente lo hacen mucho más fácil al usar los alias ya definidos para decirle a sudo quién puede hacer qué en qué hosts. Los ejemplos se explican por sí mismos una vez que comprenda la sintaxis de esta sección. Así que veamos la sintaxis que encontramos en la sección de comandos. En Figura 2 tenemos una entrada genérica para nuestro usuario, ruser.
ruser ALL=(ALL) ALL Figura 2 :Una entrada genérica que dice que ruser puede ejecutar cualquier programa en cualquier host como cualquier usuario.
El primer TODO de la línea indica que esta regla se aplica a todos los hosts. El segundo ALL permite al usuario ejecutar comandos como cualquier otro usuario. De forma predeterminada, los comandos se ejecutan como usuario raíz, pero el usuario puede especificar en sudo línea de comando que un programa se ejecuta como cualquier otro usuario. El último ALL significa que el usuario puede ejecutar todos los comandos sin restricciones. Esta entrada convertiría efectivamente a ruser en root. No usaremos esta entrada porque no queremos que este usuario tenga todas esas capacidades.
Tenga en cuenta que hay una entrada para root como se muestra en la Figura 3 . Esta entrada permite que root tenga acceso completo a todos los comandos en todos los hosts.
root ALL=(ALL) ALL
Figura 3 :Una entrada que dice que toot puede ejecutar cualquier programa en cualquier host como cualquier usuario.
Pero, por supuesto, tenía que probar esto, así que comenté la línea en la Figura 3 y, como root, intenté ejecutar chown sin sudo . Eso funcionó, para mi sorpresa. Luego usé sudo chown y eso falló con el mensaje, “la raíz no está en el archivo sudoers. Este incidente será reportado." Esto significa que root puede ejecutar todo como root, pero nada cuando usa sudo dominio. Esto evitaría que root ejecute comandos como otros usuarios a través de sudo comando, pero root tiene muchas formas de evitar esa restricción.
La entrada en Figura 4 es el que agregué para controlar el acceso a myprog . Especifica que los usuarios que figuran en el grupo AUDIO, tal como se define cerca de la parte superior de sudoers archivo, tenga acceso solo a un programa, myprog , en un host, guest1.
AUDIO guest1=/usr/local/bin/myprog
Figura 4 :Esta es la entrada que agregué para permitir que los usuarios que forman parte del grupo AUDIO accedan a myprog en el anfitrión, invitado1.
Tenga en cuenta que la sintaxis de la línea en la Figura 4 especifica solo el host en el que se permitirá este acceso y el programa. No especifica que el usuario pueda ejecutar el programa como cualquier otro usuario.
Omitir contraseñas
Figura 5 ilustra el uso de NOPASSWORD para permitir que los usuarios especificados en el grupo AUDIO ejecuten myprog sin necesidad de introducir sus contraseñas.
AUDIO guest1=NOPASSWORD : /usr/local/bin/myprog
Figura 5 :Esta entrada hipotética permitiría a los usuarios que forman parte del grupo AUDIO acceder a myprog sin necesidad de introducir sus contraseñas.
No hice esto para mi programa porque creo que los usuarios con sudo el acceso debe detenerse y pensar en lo que está haciendo y esto puede ayudar un poco con eso. Acabo de usar la entrada de mi pequeño programa como ejemplo.
Rueda
La especificación de la rueda en la sección de comandos de sudoers archivo como se muestra en la Figura 6 permite que todos los usuarios del grupo de ruedas ejecuten todos los comandos en cualquier host. El grupo de ruedas se define en el /etc/group El archivo y los usuarios deben agregarse al grupo allí para que esto funcione. El % El signo que precede al nombre del grupo significa que sudo debe buscar ese grupo en el /etc/group archivo.
%wheel ALL = (ALL) ALL
Figura 6 :Esta entrada dice que todos los usuarios que son miembros del grupo rueda como se define en el /etc/group El archivo puede ejecutar todos los comandos en cualquier host.
Esta es una buena forma de delegar el acceso raíz completo a varios usuarios sin proporcionar la contraseña raíz. Simplemente agregar un usuario al grupo de rueda les da acceso a todos los poderes de raíz. También proporciona un medio para monitorear sus actividades a través de las entradas de registro creadas por sudo . Algunas distribuciones como Ubuntu agregan ID de usuarios al grupo de ruedas en /etc/group que les permite usar el sudo comando para usar todos los comandos privilegiados.
Caso de uso 2:La presentación
Por lo general, pensamos en las presentaciones en términos de diapositivas ingeniosas creadas por LibreOffice Impress o PowerPoint, transiciones animadas y gráficos, pero ese no tiene por qué ser el caso. El 3 de marzo de este año, presenté una sesión extendida en Open Source 101 en Columbia, Carolina del Sur, titulada "Uso y configuración de Bash".
Ahora, si asiste a una sesión larga sobre el uso de Bash, ¿por qué querría ver muchas diapositivas elegantes? Personalmente, quiero ver a Bash en uso. Así que creé un script de Bash que se convirtió en mi presentación. No soy un mecanógrafo rápido o preciso, por lo que esto también me permitió preprogramar todos los comandos que quería demostrar en el script Bash, por lo que solo tendría que presionar Enter para pasar a la siguiente diapositiva que contiene texto o para emitir un comando. Esto funcionó muy bien para mí y a los asistentes pareció gustarles también porque era un muy buen caso de uso para los scripts de Bash.
Esto es relevante porque uno y solo uno de los comandos en este script de shell Bash de 1500 líneas requería privilegios de root. Sería increíblemente inseguro iniciar sesión como root y ejecutar todo el programa. ¿Qué sucede si se produce un error que eliminó o destruyó algunos archivos importantes a nivel del sistema? Como administrador de sistemas y programador de Bash, no soy perfecto y ocurren errores.
Entonces, la respuesta fue ejecutar el programa como usuario "estudiante" y usar sudo comando como prefijo del único comando que requería acceso privilegiado. Incluso en medio de mi presentación, escribir la contraseña para el usuario estudiante fue fácil. También usé esto en mi presentación como ejemplo de un uso apropiado de sudo .
La configuración para este caso de uso es la misma que para el caso anterior, solo que con diferentes nombres de usuario y nombres de comando.
Pensamientos finales
He usado sudo en estos casos para un objetivo muy limitado:proporcionar acceso a uno o dos usuarios a un solo comando. Logré esto con dos líneas si ignora mis propios comentarios. Delegar la autoridad para realizar tareas específicas a usuarios que no tienen acceso raíz es simple y puede ahorrarle mucho tiempo como administrador de sistemas. También puede mejorar significativamente la seguridad al proporcionar acceso a comandos específicos solo cuando sea necesario.
El sudo El comando también genera entradas de registro que pueden ayudar a detectar problemas. Los sudoers file ofrece una plétora de capacidades y opciones para la configuración. Compruebe el man archivos para sudo y sudoers por los detalles bajos y sucios.
[ Descargar ahora:una guía para administradores de sistemas sobre secuencias de comandos Bash. ]