Cuando Ubuntu solicita la contraseña de un usuario administrador, ¿cómo decide qué usuario administrativo solicitar?

Estoy configurando una máquina Ubuntu (10.10) que será utilizada por varias personas. Es una máquina compartida en una pequeña oficina. Sus funciones principales son alojar máquinas virtuales con VirtualBox y servir archivos con Samba.

Para Samba, se deben configurar varias cuentas de usuario para que varias personas puedan conectarse a los recursos compartidos de Samba desde sus propias estaciones de trabajo. Sin embargo, también hay una cuenta que se dedica a ejecutar máquinas virtuales, que utilizarán varias personas. A veces, las personas intentan hacer cosas con esta cuenta que requieren privilegios elevados; esto hace que aparezca el cuadro de diálogo "Ingrese la contraseña de un usuario administrativo" de Gnome. Sin embargo, este cuadro de diálogo solicita mi contraseña: cuando configuré la máquina, la mía fue la primera cuenta creada, por lo que parece suponer que soy el único usuario con poderes de sudo.

Quiero designar a otro usuario como "administrador de primer recurso", por así decirlo, y no puede ser el usuario de la cuenta compartida, porque todos deben conocer la contraseña de esa cuenta, por lo que quiero que sus privilegios sean estrictamente limitados. No puede ser mi cuenta, ya que de ninguna manera estoy informando a otras personas mi contraseña, y no estaré presente en el sitio con la frecuencia suficiente para ingresarla yo mismo. Sin embargo, hay alguien que puede hacer esto en persona, así que los agregué /etc/sudoers. ¿Cómo puedo decirle a Ubuntu que cuando necesita elevar los privilegios para algo, primero debe pedir su cuenta?

Para resumir:

• Cuentas en la máquina: Alice, Bob, Carol, Dave, Eliza.
• Cuando se instaló Ubuntu, Alice fue el primer usuario, agregado durante el proceso de instalación.
• "Dave" es en realidad una cuenta que usan muchas personas, que no pueden estar /etc/sudoersporque su contraseña es de conocimiento público.
• Se ha configurado a Bob para que sea una cuenta "administrativa" en Gnome y se ingresa de manera apropiada /etc/sudoers: Bob es el jefe de esta oficina.
• Cuando se intentan acciones que requieren privilegios elevados mientras está conectado como Bob, Carol, Eliza o Dave, el sistema debe solicitar las credenciales de Bob.
• Cuando se intentan acciones que necesitan privilegios elevados mientras se inicia sesión como Alice, el sistema debe solicitar las credenciales de Alice (aunque Alice es una especie de administrador de sistemas buckaroo y tiene la costumbre de usar su -para hacer tareas administrativas extendidas).

¿Qué cambios de configuración necesito hacer para lograr el estado deseado aquí?

Antes que nada, permítanos señalar que se permiten acciones privilegiadas para un usuario no root a través de dos mecanismos diferentes.

1. sudo

2. PolicyKit

El primero se usa cuando ejecuta explícitamente un comando con sudoo un elemento de menú cuyo comando está envuelto gksu(como Synaptic Package Manager ).
En este caso, la contraseña requerida es la del usuario que invoca, generalmente el usuario que inició sesión.

El segundo se usa cuando una aplicación compatible con PolicyKit intenta realizar una acción privilegiada. En tal caso, la aplicación pregunta a la autoridad local PolicyKit (a través de D-Bus) si la acción puede ejecutarse. La Autoridad Local luego, a través de un Agente de Autenticación, le pide al usuario activo que pruebe su identidad. La ventana de diálogo es la siguiente (desafortunadamente con texto en italiano :)

Puede identificar PolicyKit desde el pequeño triángulo negro y la etiqueta Detalles . Como puede ver, si hay más de un usuario en el admingrupo, puede elegir de la lista qué usuario usar para la autenticación.

Dado todo esto, ambos sudoy PolicyKit son mucho más complicados, con respecto a las configuraciones que se pueden lograr: puede configurar acciones que se pueden ejecutar sin contraseña, ejecutadas solo por un usuario o grupo en particular, etc.

En cuanto a su pregunta, cuando el mecanismo utilizado por la aplicación es PolicyKit, independientemente del usuario conectado actualmente, la contraseña requerida sería la de Bob o Alice (los dos únicos usuarios administradores, si entiendo correctamente), y puede cambiar de la lista qué usuario desea usar para la autenticación.

Cuando el mecanismo utilizado por la aplicación es sudo(para las tareas de administración realizadas a través de la GUI, esto se está volviendo menos frecuente), no tiene un medio inmediato y simple para elegir el usuario para la autenticación.

Claramente, sudosería la primera opción para mí en tal caso. Los principales aparece punto a ser que la mayoría de los administradores (reales) no utilizan realmente /etc/sudoersen toda su extensión posible ( User_Alias, Runas_Alias, Host_Alias, Cmnd_Alias).

La mayoría de los administradores terminan usando solo algunas de las reglas existentes y agregando usuarios, o peor, simplemente agregando usuarios al sudogrupo para el que generalmente existe una regla en las configuraciones de Ubuntu ( %sudo...). Esto, por supuesto, le da a los respectivos usuarios un reinado gratuito y el poder total de la cuenta de superusuario.

Dado su comentario:

así que los agregué a /etc/sudoers

Creo que tampoco lo usas en la medida de lo posible.

En un escenario como el suyo, literalmente escribiría las pocas acciones a las que se limitaría Bob. De hecho, esto es lo que hice en un servidor que mantengo, para permitir que dos usuarios particulares reinicien un invitado KVM particular en un host. Los scripts contendrían un hashbang con ruta absoluta al intérprete (por ejemplo, en #!/bin/dashlugar de #!/usr/bin/env bash) y probablemente se ejecutarían con un shell que se usa en otro lugar para tareas privilegiadas ( /bin/dasho /bin/sh). Esas son solo precauciones. Aparte de eso, me aseguraría de codificar todas las rutas absolutas a los archivos binarios y usar la menor cantidad posible. Por ejemplo, cuando use bash/ dashpreferiría builtins sobre commands (ver man bash). Puede hacer que esto se pueda mantener asignando una variable a la ruta absoluta y haciendo referencia al programa basado en esa variable ($VIRSHen lugar de /usr/bin/virsh). Si puede, examine el código de cualquier script externo antes de llamarlo. Especialmente si necesita llamarlos en un contexto privilegiado. En mi caso, también confino a los usuarios en un directorio raíz particular y un subsistema SSH particular, ya que solo se conectan a la máquina mediante sshduna autenticación de clave pública. Obviamente no necesitas eso.

Asegúrese chown root: <the-script>; chmod u=rw,a=,a+rx <the-script>de evitar que alguien que no sea el rootadecuado juegue con él. También tenga cuidado con setuidy los setgidbits habilitados en los binarios de destino ( findse pueden usar para detectarlos). Supongamos por el momento que reside tu script /usr/sbin/priv-action.

Ahora edita tu /etc/sudoers. noexectambién se puede usar para evitar otros binarios que los permitidos explícitamente. En realidad, hay muchas configuraciones adicionales, no solo las que describo aquí. Así que asegúrese de consultar man sudoers.

Ahora prefiero nombrar a los usuarios ( User_Alias) en mi sudoersarchivo, pero también podría usar un Group_Alias( man sudoers) o un grupo de sistema real (por ejemplo %sudo):

# The list is comma-separated: bob,alice,...
User_Alias      LIMITED_ADMINS=bob

y luego agregue un alias de comando para permitir ejecutar ese script en particular:

# The list is comma-separated: /usr/sbin/priv-action,/bin/bash,...
Cmnd_Alias      PRIV_ACTION=/usr/sbin/priv-action

Por último, pero no menos importante, viene la línea mágica para permitir bob(o más bien a los usuarios enumerados a continuación LIMITED_ADMINS) ejecutar los comandos privilegiados a través del script:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

A diferencia de las definiciones de alias anteriores, esa línea requiere una explicación. Así que primero profundicemos en las partes en una línea de "Especificación del usuario". Aquí man sudoersayuda:

La estructura básica de una especificación de usuario es who where = (as_whom) what.

Línea de ejemplo (que se encuentra en la mayoría de las configuraciones de Ubuntu):

root    ALL=(ALL) ALL

Esto dice que un usuario llamado root (use #0para vincularlo al UID 0) puede, en todos los hosts, ejecutarse en cualquier contexto de usuario, pero se le pedirá su contraseña (asumiendo el comportamiento predeterminado). Agregar la NOPASSWDetiqueta antes de la última ALLtambién permitiría roothacer lo mismo sin que se le pida una contraseña (así:) root ALL=(ALL) NOPASSWD:ALL. ALLes un alias intrínseco comodín para los distintos tipos de alias.

Pero volviendo a Bob:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

permitiría boby otros miembros de la lista User_Alias LIMITED_ADMINSejecutar (en todos los hosts, para eso ALLes) como usuario root(grupo implícito, pero podría darse, ver man sudoers) los comandos dados en el Cmnd_Alias PRIV_ACTION. Se pone mejor. Aún suponiendo que escriba este script, podría permitir varios parámetros, evitando así escribir múltiples scripts. /etc/sudoerscon mucho gusto toma comodines con forma de shell para limitar las posibilidades de argumentos permitidos.

Constantemente he descubierto que los administradores no usan sudoersla forma en que debería usarse, por eso aprecié el respectivo "Hack" de los dos libros "Linux Server Hacks" y "Linux Server Hacks Volume Two", que me ayudaron a comenzar con Un uso más sofisticado de esta gran instalación.

Puede encontrar todo tipo de soluciones intrincadas, que pueden no ayudar exactamente al aspecto de seguridad, para su caso particular, pero una vez que hable el vocabulario básico /etc/sudoers, puede realizar hazañas bastante mágicas :)

NB: tenga en cuenta que también puede crear un nuevo archivo debajo /etc/sudoers.d/si lo desea. Esto supone que /etc/sudoerscontiene la línea:

#includedir /etc/sudoers.d

Solo hay un superusuario en Unix / Linux, su nombre es root, pero los sudoers son usuarios que pueden convertirse en root. Debes usar grupos:

newgrp admins

y luego asigne los usuarios a ese grupo:

chgrp alice admins

luego agregue el grupo de administradores al archivo de configuración de sudoers como si el grupo fuera un usuario.

Actualizar

O puede agregar cualquier usuario al grupo de administración:

chgrp alice admin