Siempre ha sido mi ideología que, como usuario, puedes hacer lo que quieras en Linux y para todo lo demás, siempre lo hay sudo. sudopermite ejecutar pocas cosas como algunos otros usuarios, en la mayoría de los casos como rootpara la administración del sistema. sudoHa sido un recurso de mayor ventaja para delegar algunas de mis tareas y privilegios de rutina como usuario (root) a otros y ayudar a administrar mi tiempo y el tiempo de otros mejor sin elevar los privilegios más allá de lo requerido. Al mismo tiempo, es mi confianza en ellos lo que mantiene sus entradas presentes en elsudoersarchivo de configuración. No estoy seguro de si podría estar relacionado, pero lo que puedo decir es que sudo le brinda una mejor perspectiva de seguridad de quién y qué pueden hacer con sus privilegios de confianza. Incluso si algo sale mal, son responsables. (Siempre puedo hacer un poco astuto con información de registro de sudoers para encontrar a los culpables también). Mis muchachos siempre me han expresado su preocupación de que tengan que escribir sudo para todo lo que querían hacer con privilegios elevados en el entorno Linux. Aquí encontré la misma pregunta también.
Para ver las soluciones y mi búsqueda para encontrar las alternativas, me encontré con los controles de acceso basados en recursosRBAC pero en otra tierra de aventuras Solariscon herramientas como pfexecetc. Este enfoque es mejor porque esto mantendría los privilegios de los usuarios ya elevados y confiaría sobre la conciencia y el estado de alerta de lo que los administradores de sistemas querrían hacer con sus privilegios.
Teniendo en cuenta las soluciones disponibles de RBAC y sus implementaciones en el mundo Linux, me encontré con
SELinux http://www.ibm.com/developerworks/linux/library/l-rbac-selinux/
grsecurity http://en.wikipedia.org/wiki/Grsecurity
y aunque hay algunas otras implementaciones, las consideraría en el orden superior de la lista. Implementar RBAC es mucho trabajo en una organización, especialmente cuando hay muchos usuarios. RBAC sería una mejor solución en entornos homogéneos. Sin embargo, cuando hay instalaciones heterogéneas de Unix en la red y la base de datos de usuarios es común, entonces esto podría fallar. Dado que SELinux no es escalable / implementado en Solaris y las herramientas RBAC / pfexec no están implementadas en Linux. Existen diferentes enfoques para hacer una sola cosa. Por ejemplo: http://blogs.oracle.com/darren/entry/opensolaris_rbac_vs_sudo_howto
Es posible que las diferentes instalaciones de la red no admitan este enfoque (sin embargo, openrbac podría considerarse como un enfoque de implementación común) como sudoers es un enfoque de host único o no es capaz de una configuración centralizada en la red / dominio./etc/sudoersdebe sincronizarse cada vez que hay un cambio. Además, existe un requisito de base de conocimiento al operar el archivo sudoers, es necesario comprender el lenguaje de política de la configuración de sudoers para no cometer errores y permitir subvenciones. RBAC puede ofrecer un enfoque centralizado en cierta medida, mientras que los perfiles de seguridad pueden ser comunes, agregar / eliminar un usuario del rol otorgado se puede hacer desde un solo lugar (ese es el lugar donde se almacena la información del usuario / contraseña / grupo para el dominio como LDAP, NIS o AD). Esto también requeriría implícitamente comprender los comandos requeridos para operar en la base de datos RBAC como smexec, smmultiuser, ser pocos.
Sudo puede ofrecer un enfoque más multiplataforma aquí aún si funciona en todas las plataformas Unix / like que ofrecen las funciones setuid. Ambos sudoy RBAClogran dar a los usuarios no root algunos privilegios que se pueden hacer sin dar la rootcontraseña en sí. Sudo puede proporcionar un enfoque más fino / granular basado en los argumentos de la línea de comandos que se pueden usar mientras se ejecutan los comandos y restringir únicamente a qué comando con argumentos se puede ejecutar con privilegios elevados. Si bien RBAC puede restringir el uso hasta los comandos o binarios instalados, pero no tiene ningún control sobre los argumentos de la línea de comandos. La auditoría es mucho mejor y está integrada en el entorno RBAC, mientras quesudo, depende de la configuración y también de las restricciones de seguridad tomadas (como no otorgar el shell y, en particular, los hosts pueden iniciar sesión en los otros hosts sin ningún problema). Estas son solo algunas de las diferencias que podría citar y personalmente tengo una inclinación a usar sudo que RBAC, aunque con las limitaciones mencionadas podría superar la implementación de algunas soluciones. Hasta que RBAC aborde todos los problemas para mejorar la ventaja de sudo, no creo que sudo desaparezca porque es simple.