Por una razón que realmente no entiendo, todos quieren sudo para todos y para todo. En el trabajo incluso tenemos tantas entradas como formas de leer un archivo de registro (head/tail/cat/more, ...).
Creo que sudo está derrotando aquí.
Prefiero usar una combinación de directorios setgid/setuid y agregar ACL aquí y allá, pero realmente necesito saber cuáles son las mejores prácticas antes de comenzar.
Nuestros servidores tienen %admin, %production, %dba, %users, es decir, muchos grupos y muchos usuarios. Cada servicio (mysql, apache, ...) tiene su propia forma de instalar privilegios, pero los miembros del grupo %production deben poder consultar el archivo de configuración o incluso los archivos de registro. Todavía existe la solución para agregarlos a los grupos correctos (mysql...) y establecer el permiso adecuado. Pero no quiero modificar a todos los usuarios, no quiero modificar los permisos estándar, ya que podrían cambiar después de cada actualización.
Por otro lado, configurar acls y/o mezclar setuid/setgid en directorios es algo que podría hacer fácilmente sin "desfigurar" la distribución estándar.
Qué piensas sobre esto ?
Tomando el ejemplo de MySQL, se vería así:
setfacl d:g:production:rx,d:other::---,g:production:rx,other::--- /var/log/mysql /etc/mysql
¿Crees que esto es una buena práctica o definitivamente debería usar usermod -G mysql y jugar con el sistema de permisos estándar?
Gracias
Respuesta1
Mejores prácticas: mantenga el archivo sudoers y use sudo.
En mi máquina personal, prefiero setuid/gid, pero soy el único en mi computadora; y no lo hago con nada descaradamente peligroso como rm.
Respuesta2
Las mejores prácticas (y las más comunes) tienden a utilizar sudo. Sudo le ofrece un control detallado y la configuración puede manejar varias máquinas a la vez.
El uso de ACL puede complementar esto: sudomaneja operaciones como root; Las ACL otorgan y quitan derechos sobre directorios y archivos a usuarios y grupos. No contaría con setgid y setuid para hacer nada razonable.
También implementaría el grupo de ruedas; esto ayudará a aumentar la seguridad. Verifique si su suprograma admite el grupo de ruedas.
Una cosa más: si tiene viewo lessquiere leer un archivo de registro, entonces está en riesgo: ambos programas ofrecen acceso al shell.
Respuesta3
Me parece que la opción sudoers es un poco más compacta que setuid/setguid/ACL.
Sin agrupar usuarios, su ACLS será muy larga. Y si agrupa usuarios, volverá al mismo lugar donde empezó.
El mayor problema es que sin algún tipo de gestión central, el control de acceso se extiende por todo el sistema de archivos. Por supuesto, puedes solucionarlo fácilmente con, por ejemplo, macros, plantillas, gestión de configuración, etc. Pero esa es otra capa que no hace nada para reducir la complejidad.
En mi pequeña tienda Drupal uso bastante las ACL para todos los archivos de trabajo, pero sudo para todos los accesos de administración. La capa de gestión de configuración que estoy usando es Ansible y lo bueno de esto es que puedo crear fácilmente plantillas de usuarios, sus roles y, por lo tanto, qué grupos obtienen, en qué máquinas, etc. Sudoers se gestiona de manera similar. Esa me parece una buena práctica porque es más transparente.
Por supuesto, probablemente no tenga tantos usuarios o grupos como tú. También podría imaginarme poner ACL en la gestión de configuración. Pero por mi vida, no veo una forma sencilla de administrar muchas máquinas, muchos usuarios y muchos grupos de esa manera.