¿Por qué no funciona la opción sudoers NOPASSWD?

75

Tengo una línea NOPASSWD en / etc / sudoers (editado con visudo)

gatoatigrado    ALL=(ALL) NOPASSWD: /bin/set-slow-cpufreq

Sin embargo, la salida es,

gatoatigrado@coral:~> sudo -n /bin/set-slow-cpufreq
sudo: sorry, a password is required to run sudo

Este tipo de comando funciona en una máquina OpenSuSE, pero no en Ubuntu 11.10. ¿Qué estoy haciendo mal?

Nota : No puedo encontrar ningún mensaje de registro del sistema relevante, por ejemplo, a través de tail -f /var/log/syslog.

editar

Aquí está / etc / sudoers.

Defaults    env_reset

# things I've tried copying from an opensuse machine
Defaults always_set_home
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE"

root    ALL=(ALL:ALL) ALL
gatoatigrado ALL=NOPASSWD: /bin/set-slow-cpufreq
%admin ALL=(ALL) ALL
%sudo   ALL=(ALL:ALL) ALL
sudo gatoatigrado
fuente
2
¿Puede mostrar el total sudoers, el orden de las reglas no es irrelevante.
enzotib

Respuestas:

118

Debería poner esa línea después de la línea con la regla para el sudogrupo, porque, como sudoersdice la página del manual:

   When multiple entries match for a user, they are applied in order.
   Where there are multiple matches, the last match is used (which is not
   necessarily the most specific match).
enzotib
fuente
55
Como nota adicional, esto también se aplica a los usuarios en varios grupos: por ejemplo, el usuario está en el grupo admin y sudo grupo si la regla para sudo es posterior a admin, entonces la regla para sudo anula la regla de administrador para el usuario en ambos grupos.
Populus
2
¡Gracias! Agregué mi línea al final de /etc/sudoersy ahora funciona. Explicación completa aquí para las personas interesadas: techglimpse.com/ubuntu-sudoers-nopasswd-option-not-working
elimisteve
4

Idealmente, si está personalizando qué comandos se pueden ejecutar sudo, debe realizar estos cambios en un archivo separado en /etc/sudoers.d/lugar de editar el sudoersarchivo directamente. También debe usar siempre visudopara editar los archivos.

Ejemplo: sudo visudo -f /etc/sudoers.d/slowcpu

Inserte su línea otorgando permiso: gatoatigrado ALL=NOPASSWD: /bin/set-slow-cpufreq

Luego guarde y salga y visudole avisará si tiene algún error de sintaxis.

Puede ejecutar sudo -lpara ver los permisos que se le han otorgado a su usuario, si alguno de los NOPASSWDcomandos específicos del usuario aparece ANTES de cualquier %groupyouarein ALL=(ALL) ALLcomando en la salida, se le solicitará su contraseña.

Si te encuentras creando muchos de estos archivos sudoers.d, entonces quizás quieras crearlos nombrados por usuario para que sean más fáciles de visualizar. Tenga en cuenta que el orden de los NOMBRES DE ARCHIVO y de las REGLAS dentro del archivo es muy importante, el ÚLTIMO cargado gana, ya sea MÁS o MENOS permisivo que las entradas anteriores.

Puede controlar el orden de los nombres de archivo utilizando un prefijo de 00-99 o aa / bb / cc, aunque también tenga en cuenta que si tiene CUALQUIER archivo que no tenga un prefijo numérico, se cargará después de los archivos numerados, anulando la configuración. Esto se debe a que, según la configuración de su idioma, la "clasificación léxica" que utiliza el shell clasifica primero los números y luego puede intercalar mayúsculas y minúsculas al ordenar en orden "ascendente".

Intente ejecutar printf '%s\n' {{0..99},{A-Z},{a-z}} | sorty printf '%s\n' {{0..99},{A-Z},{a-z}} | LANG=C sortpara ver si su idioma actual se imprime, AaBbCcetc. o ABCluego abcpara determinar cuál sería el mejor "último" prefijo de letra para usar.

dragon788
fuente
Estoy de acuerdo con ésto. Parte de la lógica en la edición del archivo / etc / sudoers parecía contraria a la intuición: no pude lograr que% wheel ALL = (ALL) NOPASSWD: ALL funcionara de la manera en que estaba escrito en sudoers hasta que leí una publicación donde alguien dijo el #includedir La línea /etc/sudoers.d tenía que estar antes de las otras líneas como% SUDO y% WHEEL. Cuando puse el directorio #include encima de los otros permisos de grupo, comenzaron a funcionar. Entonces hice archivos para cada grupo en /etc/sudoers.d/ numerados en el mismo orden en que estaban en el archivo sudoers, pero la raíz ALL = (ALL) ALL todavía tenía que ser sudoers debajo de la línea #includedir. Extraño.
AveryFreeman
En realidad, creo que el incluido debería permanecer al final de los sudoers. Lo que probablemente estaba viendo es que uno de los otros archivos en su sudoers.d estaba deshaciendo su cambio. Es posible que también haya tenido una línea más abajo en su archivo principal que estaba restringiendo el grupo de rueda. Tenga en cuenta que sudoers se procesa donde gana la última regla para aplicar a un comando o grupo, por lo que ser más específico ayuda, pero si un comando general CUALQUIERA llega al final y no tiene NOPASSWD, anulará sus excepciones anteriores. Es por eso que debe tener sus reglas en archivos separados para que se procesen más tarde.
dragon788
No lo creo, fue una nueva instalación de Arch. Todo lo que hice fue probar y descomentar esa línea. Pero definitivamente es algo bueno para comprobar, gracias.
AveryFreeman
Algunos sistemas no usan realmente wheel y en su lugar usan un grupo llamado sudo o adm o admin. No recuerdo el comportamiento de Arch, pero puedes correr idy ver a qué grupos perteneces.
dragon788
El arco usa rueda.
AveryFreeman
4

Me encontré con esto también.

Mi situación es que estoy configurando un sistema remoto que funcionará sin cabeza. He habilitado el cifrado de disco completo (de lo contrario, un atacante con acceso físico puede hacer lo que quiera) Solo quiero autenticar con clave de pub (desarmaré la contraseña para que el esquema "tener algo, saber algo" sea una contraseña par de claves protegido: el inicio de sesión de raíz está, por supuesto, desactivado por completo)

El instalador de Ubuntu solicita un usuario administrador no root que se agrega al grupo sudo. Luego me agregué manualmente al sudoersarchivo usando sudo visudo:

my_username ALL=(ALL:ALL) NOPASSWD:ALL

NOTA: si usa nopasswd en su computadora portátil, siempre debe bloquear su computadora mientras se aleja, de lo contrario, un atacante casual puede comprometerse mucho mientras se levanta para poner crema en su café

Todavía tenía que autenticar con contraseña.

La respuesta de enzotib es la clave de lo que está sucediendo. El sudo grupal aparece en sudoers después de la entrada de mi nombre de usuario.

En lugar de mover mi entrada debajo de la línea de sudo, simplemente eliminé la línea que había agregado previamente y luego agregué NOPASSWDa la entrada para%sudo

Eso parece funcionar. Nuevamente, solo use nopasswd si realmente lo necesita (en mi caso fue precisamente lo que necesitaba, para la mayoría de los usuarios que requieren una contraseña para la actividad de sudo es mejor)

ADVERTENCIA adicional: siempre edite sudoers con visudo. (sudo visudo) Además, tener otra ventana abierta cambiada al usuario raíz le permite recuperar cualquier error que pueda cometer al cambiar el archivo sudoers.

jorfus
fuente
Nunca es una buena idea habilitar NOPASSWD contra alguno / todos los comandos, esto significa que cualquier persona que ingrese a su sistema y logre ingresar a un usuario en el grupo de sudo podrá hacer ALGO MALO a su sistema MUY rápidamente. Puedo hacer esto fácilmente con solo unos minutos de acceso usando un LiveCD o engañando a su usuario para que ejecute un cmd llamado sudoque use sus propios permisos para agregar otro usuario al grupo sudo además de ejecutar el comando solicitado.
dragon788
2
No hagas declaraciones generales como esta. En un sistema sin cabeza, no es deseable establecer una contraseña de inicio de sesión (confiando en pares de llaves). He habilitado el cifrado de disco completo, así que buena suerte con ese CD en vivo. (que por cierto te permitiría hacer todo tipo de cosas divertidas en un sistema no encriptado, independientemente del archivo sudoers) Además, no puedes escribir en ninguna de las ubicaciones en mi RUTA y no te estoy dando shell para empezar a menos que confíe en que no intentes subvertir el sistema. Su inquietud de seguridad no es inválida, simplemente está desactualizada y no es tan universalmente aplicable como implica.
jorfus
Para aquellos que no tienen una comprensión profunda de la seguridad como usted, este tipo de recomendación es probablemente mejor que la alternativa, pero estoy de acuerdo en que no es ideal.
dragon788
@ dragon788 Es cierto que quizás ambos podamos editar nuestras respuestas para ayudar a los usuarios de todos los niveles a dar un paso hacia una mayor seguridad. Agregaré una advertencia para habilitar el cifrado de disco completo para evitar compromisos cuando un atacante tiene acceso físico y una nota de que si un usuario de una computadora portátil olvida bloquear su computadora en público, sudo nopasswd podría generar un compromiso rápido. (Aunque me gustaría proponer la creación de un bloqueo de cinco minuto y la pantalla de bloqueo de teclas rápidas en realidad podría conducir a una mejor seguridad.)
jorfus
Excelente actualización, mi respuesta no tiene ninguna recomendación fuerte aparte de estos comentarios aquí, e irónicamente en el trabajo donde uso el cifrado de disco completo, terminé habilitando NOPASSWD porque tengo una contraseña muy segura que se vuelve difícil de escribir. repetidamente, y uso xautolock para bloquear mi máquina después de un corto tiempo de inactividad.
dragon788
0

En el sistema remoto, suelte el cifrado, pero deje que todo sea propiedad de una raíz como en el grupo de "Administradores", ¡eso no es 0!
Puede enmendar #sudo -g Administrators a aquellos que necesitan acceso completo, no en el sudo archivo, sino en el .loginperfil. Cualquier script estándar ahora puede tener acceso al control remoto como "root" y puede proteger los archivos que deben protegerse.
Otro "grupo" útil es "Sandbox" con un directorio de inicio de sesión en el caché del navegador y puede leerlo libremente y nada más. Utilice mayúsculas primer carácter.

Knut H
fuente