Estamos teniendo un pequeño problema en un servidor. Queremos que algunos usuarios puedan hacerlo, por ejemplo, sudoy convertirse en root, pero con la restricción de que el usuario no puede cambiar la contraseña de root. Es decir, una garantía de que aún podemos iniciar sesión en ese servidor y convertirnos en root sin importar lo que hagan los otros usuarios.

¿Es eso posible?

Queremos que algunos usuarios puedan hacerlo, por ejemplo, sudoy convertirse en root,

Bueno, ese es el problema que sudo está diseñado para resolver, por lo que esa parte es bastante fácil.

pero con la restricción de que el usuario no puede cambiar la contraseña de root.

Puede, como SHW señaló en un comentario, configurar sudo para que solo ciertos usuarios puedan tomar ciertas acciones como root. Es decir, puede permitir que el usuario1 haga sudo services apache2 restart, permitir que el usuario2 haga sudo rebootpero nada más, mientras permite que lo user3haga el administrador contratado como sistema sudo -i. Hay procedimientos disponibles sobre cómo configurar sudo de esa manera, o puede buscar (o preguntar) aquí. Ese es un problema solucionable.

Sin embargo, un usuario al que se le ha otorgado la capacidad de sudo -iacceder sudoa un shell ( sudo bashpor ejemplo) puede hacer cualquier cosa. Esto se debe a que cuando sudo lanza el shell, sudo ya no está en la imagen. Proporciona el contexto de seguridad de un usuario diferente (a menudo root), pero no tiene voz en lo que hace la aplicación ejecutada. Si esa aplicación a su vez se inicia, passwd rootno hay nada que sudo pueda hacer al respecto. Tenga en cuenta que esto también se puede hacer a través de otras aplicaciones; por ejemplo, muchos de los editores más avanzados proporcionan facilidades para ejecutar un comando a través del shell, un shell que se ejecutará con el uid efectivo de ese proceso del editor (es decir, root).

Es decir, una garantía de que todavía podemos iniciar sesión en ese servidor y convertirnos en root sin importar lo que hagan los otros usuarios.

Lo siento; si realmente quiere decir "asegurarse de que podremos iniciar sesión y usar el sistema sin importar lo que haga alguien con acceso de root", eso (a todos los efectos) no se puede hacer. Un rápido "sudo rm / etc / passwd" o "sudo chmod -x / bin / bash" (o lo que sea que use la raíz de shell) y de todos modos estás bastante regado. "Más o menos con manguera", que significa "necesitará restaurar desde la copia de seguridad y espero que no hayan hecho nada peor que un resbalón de dedos". Puede tomar algunas medidas para reducir el riesgo de un accidente accidental que conduzca a un sistema inutilizable, pero no puede evitar que la malicia cause problemas muy graves, incluido el punto de necesitar reconstruir el sistema desde cero o, al menos, de lo conocido buenas copias de seguridad

Al otorgar a un usuario acceso root sin restricciones en un sistema, confía en que ese usuario (incluido cualquier software que pueda elegir ejecutar, incluso algo tan mundano como ls) no tenga intenciones maliciosas y no se equivoque por accidente. Esa es la naturaleza del acceso raíz.

El acceso raíz limitado a través de, por ejemplo, sudo es un poco mejor, pero aún debe tener cuidado de no abrir ningún vector de ataque. Y con el acceso a la raíz, hay muchos posibles vectores de ataque para ataques de escalada de privilegios.

Si no puede confiar en ellos con el nivel de acceso que conlleva ser root, necesitará una configuración de sudo muy estricta o simplemente no otorgar al usuario en cuestión acceso root de ninguna manera, sudo o de otro modo.

Esto es prácticamente imposible. En primer lugar, si les concedes el poder de convertirse en root , entonces no hay nada que puedas hacer para evitar que hagan algo. En su caso de uso, sudodebe usarse para otorgar a sus usuarios algunos poderes de root mientras restringe otros sin permitir que se conviertan en root .

En el escenario, lo que se necesita para restringir el acceso a la suy passwdlos comandos y abrir el acceso a casi todo lo demás. El problema es que no hay nada que pueda hacer para evitar que sus usuarios editen /etc/shadow(o /etc/sudoerspara el caso) directamente y coloquen una contraseña de root de reemplazo para secuestrar root. Y este es el escenario de "ataque" más directo posible. Los sudoers con poder irrestricto a excepción de uno o dos comandos pueden evitar las restricciones para secuestrar el acceso completo a la raíz.

La única solución, como lo sugiere SHW en los comentarios, es utilizar sudopara otorgar a sus usuarios acceso a un conjunto restringido de comandos.

Actualizar

Puede haber una manera de lograr esto si usa tickets Kerberos para la autenticación. Lea este documento que explica el uso del .k5loginarchivo.

Cito las partes relevantes:

Suponga que el usuario Alice tenía un archivo .k5login en su directorio personal que contenía la siguiente línea:
[email protected]
Esto permitiría a Bob utilizar aplicaciones de red Kerberos, como ssh (1), para acceder a la cuenta de Alice, utilizando los tickets Kerberos de Bob.
...
Tenga en cuenta que debido a que Bob retiene los tickets de Kerberos para su propio director, [email protected]no tendría ninguno de los privilegios que requieren los tickets de Alice, como el acceso de root a cualquiera de los hosts del sitio, o la capacidad de cambiar la contraseña de Alice.

Sin embargo, podría estar equivocado. Todavía estoy leyendo la documentación y todavía tengo que probar Kerberos por mí mismo.

Supongo que quiere asegurarse de tener un acceso de "administrador de emergencia", incluso si su administrador real se equivoca (pero aparte de eso, confía completamente en el administrador principal).

Un enfoque popular (aunque muy hack) es tener un segundo usuario con unuid=0 nombre común toor(raíz hacia atrás). Tiene una contraseña diferente y puede servir como acceso de respaldo. Para agregar, es probable que deba editar /etc/passwdy /etc/shadow(copiar las rootlíneas).

Es casi seguro, pero si solo necesita protegerse contra el "administrador principal" que cambia la contraseña sin previo aviso, entonces funcionará. Es trivial deshabilitar, eliminando la toorcuenta; entonces el único beneficio es tener una contraseña separada.

Alternativamente, es posible que desee buscar mecanismos de autenticación alternativos, es decir ssh, claves libnss-extrausers, LDAP, etc.

Tenga en cuenta que el administrador todavía puede equivocarse mucho. Por ejemplo, bloqueando el firewall.

Si desea tener un sistema muy seguro, considere usar SELinux, donde el usuario de Unix (por ejemplo, root) también viene con un rol que puede ser mucho más detallado. Es posible que desee otorgar acceso de administrador a la raíz, pero solo una función restringida (por ejemplo, para administrar solo apache). Pero esto requerirá mucho esfuerzo de su parte para configurar correctamente la política.

La esencia de la raíz es tener un comando sin restricciones del sistema. Podría ajustarlo con SELinux (solía haber un sitio de demostración en el que cualquiera podía iniciar sesión como root, pero su poder se vio afectado por el sistema de acceso), pero ese no es el punto. El punto es que esta es la solución incorrecta a su problema.

Ahora, no ha dicho cuál es su problema, pero si no confía en estos usuarios para mantener sus manos fuera de la contraseña de root, no tienen por qué ser root. Si necesitan administrar el servidor web, o varios dispositivos de hardware, o la unidad warp o lo que sea, configure una solución para eso. Cree un grupo superpoderoso, dele todo el acceso que necesita y agréguelos. Si necesitan ejecutar llamadas al sistema solo de root, escriba algunos programas setuid.

Por supuesto, un usuario con ese tipo de acceso (y un poco de conocimiento) probablemente podría piratear fácilmente el sistema, pero al menos está trabajando con el modelo de seguridad del sistema operativo, no en contra de él.

PD. Hay muchas formas de organizar el acceso de root para usted sin la contraseña; por un lado, si está dentro /etc/sudoers(sin restricciones) solo necesita su propia contraseña para convertirse en root, por ejemplo, con sudo bash. Pero simplemente no debería necesitar ir allí.

Probablemente sea posible, al menos en teoría, hacer esto usando SELinux . Esto le permite configurar reglas mucho más precisas sobre lo que un usuario o proceso puede o no puede hacer. Incluso con SELinux, puede ser complicado hacer que sea imposible para un usuario cambiar la contraseña de root, pero aún así puede hacer lo que sea necesario.

Realmente depende de lo que el usuario que no tiene permitido cambiar la contraseña de root realmente necesita poder hacer. Probablemente sería más fácil y seguro resolver qué es eso y otorgar esos permisos específicamente usando sudo.

Quizás debería considerar permitir que los usuarios tengan acceso de root a una máquina virtual o contenedor LXC. Eso les permitiría tener acceso raíz completo a un sistema, sin permitir que les impida iniciar sesión en el host o tomar medidas administrativas.

No sé, será prácticamente factible, pero aquí hay un truco sucio:

1. escriba un script / programa de envoltura que copie el /etc/passwdarchivo a otra ubicación, antes de llamar a realsudo
2. Permitir que el usuario normal use sudo
3. Una vez que terminó su tarea, o cuando salió de sudo, restaure el /etc/passwdarchivo

Lo sé, hay muchas cosas más y menos que debes considerar para lograr esto. Después de todo, es un truco sucio

La declaración que sudoes solo para otorgar root y no hay protección después de eso es descaradamente falsa.

Se utiliza visudopara modificar el archivo sudoers. Aquí hay una línea de ejemplo:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command

• redsandroes el nombre de usuario al que le estamos dando permiso. Ponga un %frente para que se aplique a un grupo.
• ALLes un nombre para esta regla. Los sudoers pueden hacer mucho más que simplemente otorgar permisos globales. Sin embargo, ahí es donde se complica.
• = no necesita explicación
• ALL:ALLse lee como (who_to_run_it_as: what_group_to_run_it_as). De esta manera, puede permitir ejecutar un comando, pero solo en el contexto de un usuario o grupo específico.
• NOPASSWD: le dice que desactive la solicitud de contraseña.
• /path/to/command le permite especificar comandos específicos path_to_commmand, another_command

Lo que hay que recordar es que, si bien sudolos usuarios domésticos lo usan principalmente para escalar a los privilegios de root, puede usarse y se usa para controlar el acceso a comandos específicos de una manera mucho más granular.

Referencias

• de mi otra respuesta aquí

(No conozco ubuntu, pero debería ser similar a Fedora / Red-Hat)
Lo único que puedo imaginar restringir el acceso para cambiar la contraseña de root es no dar acceso completo a la raíz, tal vez con sudo, o usar SElinux para restringir el acceso al archivo de contraseña ... pero no confiaría en que tuviera mucho acceso ya que la raíz generalmente tiene acceso sin restricciones y podría actualizar SElinux, o volver a etiquetar el archivo de contraseña o ejecutar algún programa preparado previamente para cambiar la contraseña.

Si no confías en ellos lo suficiente como para no cambiar la contraseña, probablemente no deberías darles acceso de root. De lo contrario, supongo que está tratando de evitar accidentes.

Si solo está tratando de proteger su acceso a la raíz, configure un programa que pueda restaurar la contraseña de root, por lo que incluso si se modifica, se puede restaurar con un acceso mínimo. (Sudo hace bien solo)

Su requisito es:

Tenemos un pequeño problema en un servidor [...] que es una garantía de que aún podemos iniciar sesión en ese servidor y convertirnos en root sin importar lo que hagan los otros usuarios.

Según su pregunta, parece que no se enfrenta a usuarios malintencionados al azar con la intención de destruir su sistema, sino que tiene usuarios de confianza parcial que pueden causar travesuras de vez en cuando (¿estudiantes quizás?). Mis sugerencias abordan esa situación, no un asalto total por parte de usuarios malintencionados.

1. Ejecute el servidor dentro de un entorno virtual. Podrá montar el sistema de archivos del servidor y reemplazar archivos alterados con versiones conocidas. Dependiendo del posible daño que anticipa, puede tomar una instantánea de todos los directorios críticos (/ bin, / sbin, / etc, / usr, / var, etc.) y expandir la instantánea para sobrescribir los archivos dañados mientras deja el resto del sistema intacto

2. Ejecute el sistema de solo lectura, por ejemplo, desde un DVD-R. Si puede vivir con la mayoría de las partes del sistema estáticas hasta el próximo reinicio, esta es una buena opción. También puede usar una tienda de respaldo de solo lectura con un entorno virtual o cargar el sistema base a través de la red, haciendo que los cambios entre reinicios sean mucho más fáciles que escribir un nuevo DVD-R.

3. Módulos del kernel. Los módulos de seguridad de Linux (LSM) del núcleo proporcionan la base para crear módulos seguros. LSM es utilizado por SELinux, pero también es utilizado por varios sistemas menos conocidos y más simples, como Smack, TOMOYO y AppArmor. Este artículo tiene una buena descripción de las opciones. Lo más probable es que uno de ellos se pueda configurar de forma inmediata para evitar el acceso de escritura a / etc / passwd, / etc / shadow, o cualquier otro archivo que desee, incluso por root.

4. La misma idea que # 1, pero cuando el servidor no está en un entorno virtual. Podría hacer que el servidor se cargue en cadena en un sistema operativo de solo lectura, como un CD en vivo, que montaría automáticamente el sistema de archivos del servidor y sobrescribiría el sistema base en cada arranque con copias en buen estado. El sistema operativo de solo lectura se iniciará en el sistema operativo principal.

5. Nuevamente, suponiendo que se trata de usuarios de confianza parcial que rinden cuentas a un superior (maestro / jefe), la mejor respuesta puede ser la Auditoría de Linux . De esta manera, sabrá cada acción relevante para la seguridad que se haya tomado y quién la tomó (sabrá quién la tomó porque, incluso si todos los usuarios comparten la cuenta raíz, primero habrán sudo'do de su cuenta de usuario). De hecho, incluso podría analizar el registro de auditoría en tiempo real y reemplazar los archivos dañados. / etc / sombra sobrescrita? No hay problema, solo haga que el servidor de monitoreo lo reemplace instantáneamente con una versión buena conocida.

Otras tecnologías que puede investigar según sus necesidades:

• Arquitectura de medición de integridad de Linux / Módulo de verificación extendido (IMA / EVM), y
• Módulos de plataforma de confianza (TPM).

Para complementar las otras respuestas, voy a asumir que el escenario es que percibes que perder el control de la raíz es una situación rara, y que en esos casos se permite reiniciar el servidor. (Después de todo, si cree que la máquina se ha visto comprometida, querrá desconectarla de todos modos).

La gran ventaja de esto es que no hay nada que configurar. Su pregunta es: " He olvidado la contraseña de root, ¿cómo vuelvo a entrar? " Y la respuesta a eso es reiniciar y elegir el modo de usuario único cuando se inicia la máquina. Eso te da un shell de root sin necesidad de saber la contraseña. En ese momento, puede establecer una nueva contraseña. (Además de ir y reparar cualquier daño ...)

Si se clona el servidor en una máquina virtual (como VirtualBox ), se puede dar acceso root sin restricciones a las personas y aún garantizar que siempre tendrá acceso directo a la partición (s) del sistema operativo huésped, y por lo tanto mantener el control final sobre /etc/passwdy similares, ya que tendrás root en el sistema host.

Por supuesto, dar acceso a la raíz sin restricciones puede no ser la solución correcta: si la seguridad de los datos es un problema o su responsabilidad, no puede ceder el acceso a la raíz.

El requisito no es técnicamente posible. Como ya se comentó elocuentemente, otorgar sudoderechos ilimitados o incluso más limitados a un usuario significa que confía en ese usuario. Alguien que tiene malas intenciones y suficiente habilidad técnica y perseverancia puede atravesar cualquier obstáculo que se ponga en su lugar.

Sin embargo, suponiendo que puede confiar en que sus usuarios no serán mal intencionados, puede hacer que la restricción en el cambio de contraseña sea una cuestión de política . Puede crear un contenedor para el passwdprograma que les recuerde "no cambien la contraseña de root". Esto supone que la fuente del problema es que los usuarios que están cambiando la contraseña de root lo están haciendo debido a un malentendido (tal vez pensando que están cambiando su propia contraseña después de haberlo hecho sudo bash).

En circunstancias especiales (raras), si no es posible la confianza completa y no es posible romper el sudoacceso a fragmentos adecuados pero razonablemente seguros, puede considerar establecer sanciones organizativas contra el cambio de contraseña (o cualquier otra forma específica de alteración del sistema), organice monitoreo de recursos críticos para que no sea fácil pasar desapercibido para evitar las políticas establecidas, y ser público y transparente sobre las reglas de uso y el monitoreo.

El aspecto de monitoreo y descubrimiento es un problema técnico difícil que se beneficia de otra pregunta si elige recorrer ese camino. Me parece que necesitaríamos

1. detectar cuándo un usuario cambia la identidad a raíz y realizar un seguimiento de los procesos creados;
2. registre las creaciones de los procesos a partir de ese momento para ver quién es el usuario original responsable de cada proceso y usar el host remoto donde los usuarios de confianza parcial no tienen acceso para enviar los registros;
3. use algún tipo de rastreo del sistema para registrar lo que está sucediendo y luego poder descubrir quién estuvo detrás de la violación de la política.

Al menos tendríamos que registrar la apertura de un conjunto de archivos que no sea seguro para escritura, creación de procesos exec()y, por supuesto, cualquier intento de cambiar las redes.

La implementación podría realizarse mediante libc modificado o (mucho mejor) el seguimiento de llamadas del sistema.

Por supuesto, es imposible hacer que el rastreo y el registro funcionen correctamente al 100%, no es fácil de implementar y también requiere recursos adicionales para operar. Esto no detendría el cambio de contraseña u otra alteración indeseada del sistema, pero haría (más probable) que sea posible encontrar al usuario culpable o al menos crear una ilusión de que hay monitoreo y hacerlo menos atractivo para algunos usuarios malvados (pero algunos hackers amantes de los problemas que ven la futilidad fundamental de las medidas técnicas implementadas pueden sentirse alentados a aceptar el desafío y tratar de eludir el sistema solo por diversión).

La pregunta formulada originalmente es inútil. Parece que el objetivo principal es "todavía tener inicio de sesión", por lo que hablar de alguna entrada de emergencia que sigue funcionando con seguridad incluso con el acceso de root otorgado a otra persona. Saludos a Anony-Mousse, quien primero lo notó explícitamente.

El problema es: si el propietario tiene acceso físico a la caja, puede recuperar fácilmente el acceso lógico al sistema (siempre que esté vivo :). De lo contrario, mantener la contraseña de root no rescatará, por ejemplo, de sshd down o de una configuración de redes incorrecta, por lo tanto, el sistema aún no es accesible.

El tema sobre cómo evitar que el sistema sea dañado por una persona con privilegios administrativos parece demasiado amplio para adaptarse al formato de pregunta SE.

Hablando de la solución remota de entrada de emergencia, la mejor manera es IPMI (creo) si está disponible. El propietario del sistema puede conectar la unidad virtual en cualquier momento, arrancar desde ella y continuar con la recuperación del sistema.

Si IPMI no está disponible, puede utilizarse una tecnología de virtualización adecuada, como ya se ha propuesto anteriormente.

Puede limitar el acceso a sudo en su /etc/sudoersarchivo

Para explicar completamente la sintaxis de / etc / sudoers, usaremos una regla de muestra y desglosaremos cada columna:

jorge  ALL=(root) /usr/bin/find, /bin/rm

La primera columna define a qué usuario o grupo se aplica esta regla de sudo. En este caso, es el usuario jorge. Si la palabra en esta columna está precedida por un símbolo%, designa este valor como un grupo en lugar de un usuario, ya que un sistema puede tener usuarios y grupos con el mismo nombre.

El segundo valor (ALL) define a qué hosts se aplica esta regla de sudo. Esta columna es más útil cuando implementa un entorno sudo en múltiples sistemas. Para un sistema Ubuntu de escritorio, o un sistema en el que no planea implementar los roles de sudo en múltiples sistemas, puede dejar este valor establecido en ALL, que es un comodín que coincide con todos los hosts.

El tercer valor se establece entre paréntesis y define a qué usuario o usuarios puede ejecutar el comando en la primera columna. Este valor se establece en root, lo que significa que a jorge se le permitirá ejecutar los comandos especificados en la última columna como usuario root. Este valor también se puede establecer en el comodín ALL, lo que permitiría a jorge ejecutar los comandos como cualquier usuario en el sistema.

El último valor (/ usr / bin / find, / bin / rm) es una lista de comandos separados por comas que el usuario en la primera columna puede ejecutar como usuario (s) en la tercera columna. En este caso, estamos permitiendo que jorge ejecute find y rm como root. Este valor también se puede establecer en el comodín ALL, lo que permitiría a jorge ejecutar todos los comandos en el sistema como root.

Con esto en mente, puede permitir comandos X de una manera delimitada por comas y siempre que no agregue passwda esto, debería estar bien

No hay 1/2 raíz :) Una vez que otorgue privilegios de raíz, pueden hacer lo que quieran. Alternativamente, puede usar sudo para ejecutar un shell bash restringido o ejecutar el rbash sin privilegios de root.

Si desea tener un mecanismo a prueba de fallas para iniciar sesión en el servidor como root, puede crear otro usuario con uid=0o crear un cron simple que restablecerá la contraseña de root periódicamente.

Intente agregar un grupo de ruedas en lugar de usar sudo. sudo permite que un usuario ejecute como si fuera root, lo que significa que no es diferente de ejecutar:

su -

para convertirse en root. La raíz uid = 0; la rueda uid = 10. La gente usa los nombres pero el sistema operativo usa el uid. Ciertos comandos no pueden ser ejecutados por un miembro del grupo de ruedas. (Si usa wheel, no cometa el error de agregar root como miembro del grupo wheel). Eche un vistazo a la documentación de Red Hat si no sabe qué es la rueda.

Otra opción es usar una clave ssh en lugar de una contraseña. Asumiendo que puede estar seguro de que las personas que usan sudo no agregan sus claves públicas al archivo ~ / .ssh / certifiedkeys, esto evita cualquier preocupación sobre el cambio de la contraseña de root porque la contraseña de root se ignora de manera efectiva.

Si prefiere extender la confianza a estos usuarios (para no agregar su propia clave pública) intente usar atributos de archivo extendido y usar el bit Inmutable. Después de crear su archivo ~ / .ssh / Authorizedkeys, y después de configurar / etc / ssh / sshd_config y / etc / ssh / ssh_config como desee, configure el bit Inmutable. Claro, también hay formas de fastidiar eso: nada es perfecto.

En cualquier sistema, la información privilegiada es el mayor riesgo. La persona que dirige el espectáculo está en la cima de la pila. Un pensamiento relacionado pertenece a los contratos. Los abogados le dirán: "Nunca haga negocios con alguien con quien necesita un contrato". El sentido común nos dice: "Nunca hagas negocios sin un contrato". Cuando encuentre a alguien en quien confíe lo suficiente como para hacer negocios, escriba el contrato en función de las necesidades del otro.

Todas las respuestas enviadas, incluida la mía, no abordan el acceso físico. Quien lo tiene, tiene el control. Si no eres tú, entonces es probable que tengas una forma de conseguir que la persona que acceda físicamente a la máquina en caso de que alguien encuentre una manera de evitar que inicies sesión, o si encuentran una manera de iniciar sesión incluso después de ti He intentado evitar que eso suceda. Por supuesto, si tiene acceso físico, es posible que no necesite estas cosas, aunque se debe considerar implementar una pareja de todos modos, si está interesado en NO ser molestado.

-John Crout

Una forma sería asegurarse de que /etcno se pueda escribir. Por nadie, siempre que pueda haber un sudoeralrededor.

Eso podría hacerse montándolo a través de la red y asegurarse del otro lado de que el dispositivo no se puede escribir.

Eso podría hacerse mediante el uso de un dispositivo local que impida el acceso de escritura a él. (Busque el write blockerhardware)

La parte importante es que la restricción debe aplicarse fuera del concepto raíz de esa máquina. Un hacker creativo encontrará todos los obstáculos que coloque en ellos dentro del entorno que pueda controlar. Entonces, si root puede cambiar su contraseña, también puede hacerlo a sudoer.

Para estar seguro de que el usuario tampoco puede arruinar sus capacidades de inicio de sesión, debe tener montado solo lectura /biny /sbin.

Y tendrá que tener un script que restablezca periódicamente la conexión de red.

(Como nota al margen: si le permite al sudoer solo un conjunto muy limitado de comandos y para cada uno de ellos está seguro de que no pueden salir de ellos / reemplazarlos, etc., entonces puede evitarlo mientras se /etcpuede escribir ...)