Estoy ejecutando sudo-1.8.6 en CentOS 6.5. Mi pregunta es muy simple: ¿cómo evito que SHELL se propague del entorno de un usuario a un entorno de sudo?
Por lo general, las personas van por el otro lado: quieren preservar una variable de entorno. Sin embargo, tengo un problema en el que mi usuario "zabbix" cuyo shell /sbin/nologinintenta ejecutar un comando a través de sudo. Sudo está preservando /sbin/nologinpara que la raíz no pueda ejecutar subcapas. (Actualización: esta parte es verdadera, pero no es la variable de entorno SHELL. El problema es el valor de shell que se extrae de / etc / passwd).
Incluyo una prueba que ilustra el problema; Este no es mi caso de uso del mundo real, sino que simplemente ilustra que el SHELL del usuario que llama se conserva. Tengo un programa que se ejecuta como usuario zabbix. Llama /usr/bin/sudo -u root /tmp/doit(la programación se ejecuta como zabbixun demonio, por lo que el /sbin/nologinshell en el archivo de contraseña no lo impide). /tmp/doites un script de shell que simplemente tiene:
#!/bin/sh
env > /tmp/outfile(su modo es 755, obviamente). En outfilepuedo ver que SHELLes /sbin/nologin. Sin embargo, en este punto, el script se ejecuta como root, a través de sudo, por lo que no debería tener las variables de entorno del usuario anterior, ¿verdad?
Aquí está mi / etc / sudoers:
Los valores predeterminados requieren Por defecto! Visiblepw Valores predeterminados always_set_home Valores predeterminados env_reset Valores predeterminados env_keep = "PANTALLA DE COLORES NOMBRE DEL HOSTAL TAMAÑO INPUTRC KDEDIR LS_COLORS" Valores predeterminados env_keep + = "CORREO PS1 PS2 QTDIR NOMBRE DE USUARIO LANG LC_ADDRESS LC_CTYPE" Valores predeterminados env_keep + = "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES" Valores predeterminados env_keep + = "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE" Valores predeterminados env_keep + = "LC_TIME LC_ALL IDIOMA LINGUAS _XKB_CHARSET XAUTHORITY" Valores predeterminados secure_path = / sbin: / bin: / usr / sbin: / usr / bin: / usr / local / bin: / usr / local / sbin ## Permitir a la raíz ejecutar cualquier comando en cualquier lugar root ALL = (ALL) ALL #includedir /etc/sudoers.d
Y aquí está mi /etc/sudoers.d/zabbix:
Valores predeterminados: zabbix! Requiretty zabbix ALL = (root) NOPASSWD: / tmp / doit
Editar: Un poco más de información:
El proceso que ejecuta el sudo es zabbix_agentd, desde el software de monitoreo Zabbix. Hay una entrada en el /etc/zabbix/zabbix_agentd.d/userparameter_disk.confarchivo que se parece a:
UserParameter = example.disk.discovery, / usr / local / bin / zabbix_raid_discovery
/usr/local/bin/zabbix_raid_discoveryes un script de Python Lo he modificado para simplemente hacer esto:
print subprocess.check_output (['/ usr / bin / sudo', '-u', 'root', '/ tmp / doit'])
/tmp/doit simplemente hace esto:
#! / bin / sh env >> / tmp / outfile
Ejecuto lo siguiente en mi servidor Zabbix para ejecutar el /usr/local/bin/zabbix_raid_discoveryscript:
zabbix_get -s client_hostname -k 'ejemplo.disco.discovery'
Luego reviso el /tmp/outfile, y veo:
SHELL = / sbin / nologin TERM = linux USUARIO = root SUDO_USER = zabbix SUDO_UID = 497 USERNAME = root RUTA = / sbin: / bin: / usr / sbin: / usr / bin: / usr / local / bin: / usr / local / sbin CORREO = / var / mail / root PWD = / LANG = en_US.UTF-8 SHLVL = 1 SUDO_COMMAND = / tmp / doit INICIO = / root LOGNAME = root SUDO_GID = 497 _ = / bin / env
Esa SHELLlínea realmente me molesta. El archivo es propiedad de root, por lo que sé que está siendo creado por el usuario root, pero el shell es del usuario llamante ( zabbix).
env_delete, pero estoy de acuerdo el quid de la cuestión es que el comportamiento predeterminado de env_reset ...causes commands to be executed with a new, minimal environment.Tenemos un sistema Linux con PAM, lo que de acuerdo a la página del manual, The new environment contains the ... SHELL ... (variable). Como puede ver en mi /etc/sudoersarchivo anterior, no permitimos SHELLen el env_keep. Por SHELLlo tanto , no se debe preservar; deberíamos tener el usuario root SHELL.
zabbix ALL=(root) NOPASSWD: /bin/env SHELL=/bin/sh /tmp/doit *a mi /etc/sudoers/zabbixarchivo y tiene un shell adecuado. Gracias, ahora tengo una solución. La pregunta es, ¿por qué necesitaba incluirlo? Parece peligroso (y roto) pasar el SHELL de la persona que llama, pero no puedo encontrar ningún lugar donde sudo esté configurado para modificarlo. He corrido find /etc/sudoers /etc/sysconfig -type f -exec grep env_ {} \;y no encuentro banderas rojas; /etc/sudoerscontiene la única env_cadena Así que no creo que haya una bandera sudoers interfiriendo ...
sudo bash debe iniciar un shell bash como root y DEBE tener la variable SHELL establecida en el valor de / etc / password. Usted informa que SHELL se está configurando en (o se conserva como) /sbin/nologin. Ese es un problema de seguridad, el shell iniciado por root no debe ser controlado por una variable de entorno establecida por un usuario. Eso es algo que debes investigar.
sudo env SHELL=/bin/sh shProporciona un aviso con / bin / sh establecido como la variable SHELL en su sistema?