¿Puedo crear un superusuario * super * para poder tener un usuario que pueda negar el permiso para rootear?

34

Estaba pensando que podría ser ventajoso tener un usuario con permisos superiores al usuario raíz.

Verá, me gustaría mantener todas las actividades y casi todos los privilegios de usuario root existentes exactamente como están ahora.

Sin embargo, me gustaría la posibilidad de negar privilegios para rootear caso por caso extremadamente aislado.

Una de las ventajas de esto me permitiría evitar que se instalen ciertos archivos no deseados durante las actualizaciones. Este es solo un ejemplo de una posible ventaja.

Debido a que las actualizaciones de apt-get se ejecutan por root o con privilegios de sudo, apt-get tiene la capacidad de reemplazar ciertos archivos no deseados durante las actualizaciones.

Si pudiera negar estos privilegios a estos archivos particulares individuales, podría establecerlos como un enlace simbólico /dev/nullo posiblemente tener un archivo de marcador de posición en blanco que podría tener permisos que negarían que el archivo fuera reemplazado durante la actualización.

Además, no puedo evitar recordar una línea que se dijo en una entrevista con uno de los creadores de Ubuntu cuando el tipo dijo algo sobre cómo los usuarios confían mejor en "nosotros" (refiriéndose a los desarrolladores de Ubuntu) "porque tenemos root "que era una referencia a cómo se realizan las actualizaciones del sistema con permiso de root.

Simplemente alterar el procedimiento de instalación para evitar este problema no es absolutamente lo que me interesa aquí. Ahora que mi mente tiene gusto por la idea de tener el poder de negar el acceso a la raíz, me gustaría encontrar una manera de hacer que esto suceda solo por hacerlo.

Acabo de pensar en esto y no he dedicado mucho tiempo a la idea hasta ahora y estoy bastante seguro de que esto podría resolverse. Sin embargo, tengo curiosidad por saber si esto ya se ha hecho o si esta no es una idea o concepto nuevo.

Básicamente, parece que debería haber alguna forma de tener un súper usuario que tendría un permiso más allá del sistema en solo un grado.

Nota: Aunque creo que la respuesta aceptada se ajusta más a los criterios, realmente me gusta la respuesta de @CR. además.

Me gustaría crear un usuario real más arriba en el árbol (yo), pero creo que tendré que sentarme un día cuando tenga tiempo de resolverlo.

Además, no estoy tratando de elegir Ubuntu aquí; No lo usaría como mi distribución principal si me sintiera negativo al respecto.

permissions sudo users root mchid
fuente
44
¿De qué tipo de archivos estás hablando y por qué? " evitar que se instalen ciertos archivos no deseados _" sugiere que los archivos no existen (normalmente) y desea que dejen de hacerlo; pero "_que negaría que el archivo fuera reemplazado durante la actualización " sugiere que los archivos ya existen (con contenido presumiblemente deseable) y que no desea nuevas versiones.
TripeHound
66
Tenga en cuenta que cualquier método que evite apt(sobre) escribir archivos puede provocar un error, abortando el proceso de actualización. aptluego se negará a realizar actualizaciones o instalaciones hasta que se resuelva el "problema".
Dubu
66
"Simplemente alterar el procedimiento de instalación para evitar este problema no es absolutamente lo que me interesa aquí". Tal vez sea así, pero generalmente es la forma correcta de resolver el problema como se indicó. Se puede limitar la raíz (formalmente, root-in-userland no es el mismo nivel de acceso que el modo kernel), y hay sistemas para lograrlo, pero va en contra de la filosofía de Unix y los principios básicos de seguridad. En general, una vez que alguien tiene una raíz "parcial", es excepcionalmente difícil excluir todo lo que pueda usar para obtener la raíz "completa". Prefiero solo dar root al código de confianza.
Kevin
8
@mchid: la raíz es control total. De eso se trata. Para que no tenga control total, debe negar tantas cosas que ya no se ve como root (por ejemplo, sin instalar módulos del núcleo, sin montar dispositivos arbitrarios, etc.). Si no desea ejecutar cosas como root, no las ejecute como root. En cambio, reparta capacidades (excepto todas las equivalentes a la raíz , no se moleste con ellas) o ejecute un demonio como polkitd que realice operaciones de raíz en nombre de procesos no root.
Kevin
44
@mchid: Ese es el problema: hay una gran cantidad de formas para que los programas eludan sus restricciones. A menos que haga una lista negra de todas esas formas, cualquier programa que ejecute como "raíz restringida" aún puede convertirse en raíz completa cuando lo desee. Entonces, todo su esquema no es más que una farsa de teatro de seguridad.
Kevin

Respuestas:

83

El "usuario" que desea se llama LSM: módulo de seguridad de Linux. Los más conocidos son SELinux y AppArmor.

Con esto, puede evitar que ciertos binarios (y sus procesos secundarios) hagan ciertas cosas (incluso si su UID es root). Pero puede permitir estas operaciones gettyy sus procesos secundarios para que pueda hacerlo manualmente.

Hauke ​​Laging
fuente
2
Pero si su UID es root, ¿no pueden cambiar los permisos de selinux que les impiden acceder en primer lugar?
curious_cat
11
@curious_cat: Sí, por supuesto, debe negarle a un proceso de "raíz limitada" la capacidad de cambiar / aumentar su propio permiso. Las personas que escribieron SELinux ya pensaban en eso ...
Peter Cordes
8
@curious_cat Puede configurar los LSM para que sea completamente imposible cambiar su configuración en tiempo de ejecución. Tienes que reiniciar y dar un parámetro de kernel para eso.
Hauke ​​Laging
55
@ Joshua Si su copia de apt-get está usando Rowhammer, entonces tiene mayores problemas de los que preocuparse.
Draconis
3
@corsiKa Primero, desea restringir las personas que pueden arrancar la máquina a las personas que realmente están en la máquina, porque los sistemas son vulnerables mientras se inician. Activar un reinicio a través de la red está bien, pero permitir el control mientras se inicia no lo está. En segundo lugar, una regla de seguridad informática es que no se puede hacer nada una vez que un atacante tiene acceso físico, ya que también pueden sumergir todo en LN2 / volver a cablear el hardware / etc. Entonces, sí, se supone que alguien que puede alterar el arranque de una máquina ha "ganado" la máquina.
HTNW
51

Estás malinterpretando el concepto del rootusuario.

En inglés simple, rootestá en la "cima del árbol".

¿Qué pasa si un día decides tener un "super super usuario super", y luego el próximo mes, un "super super super usuario" (!). ¿Qué tan "arriba" del árbol te gustaría llegar? ¿Cómo barajarías todos los permisos y la jerarquía para que eso funcione? ¿Quién está siempre en la cima? Alguien tiene que estar en la cima, y ​​es root. Fin de la historia.

Las soluciones dadas aquí, incluidas AppArmor y SELinux, realmente no cambian esto. Simplemente permiten un control de grano más fino sobre los rootpermisos y procesos.

Me parece que su proceso de actualización no es adecuado para el resultado deseado. Pero eso no es culpa del rootusuario, en absoluto. En lugar de complicar demasiado las cosas, piense rooten el usuario de permisos de más alto nivel, y luego todo lo demás, debe trabajar hacia abajo.

Sé que algunas personas marcarán esto, pero no hay un nivel más alto en la jerarquía de usuarios, y todas las demás soluciones simplemente dan un control ligeramente diferente de cómo rootfuncionan los permisos. Pero no crean un nuevo usuario, con permisos más altos.

No puede tener un usuario con "más permisos" que rootporque rootrepresenta el nivel más alto de permisos posible. Usar una frase como "más control que root" es una contradicción: roottiene control total y todos los permisos posibles, por lo que no hay nada que se pueda hacer por encima.

Andy
fuente
Estaría en la parte superior, no raíz, final de la historia. Debido a que no hay un nivel más alto en la jerarquía de usuarios es la razón exacta por la que me gustaría crear un usuario más alto.
mchid
Aunque, eso es lo que quiero: control sobre los permisos y procesos de root para poder negar el permiso de root. Si de alguna manera puedo negar el permiso para rootear sin crear un nuevo usuario con SELinux o AppArmor, entonces supongo que no necesito un nuevo usuario. Quiero control total, más control que root.
mchid
16
No puede tener un usuario que tenga "más permisos" que root. Ese es todo el problema. El usuario que está buscando crear es esencialmente el usuario raíz. Debe abordar esto de otra manera, como crear un usuario con rootprivilegios, y luego negar ciertos en los que desea un control más preciso. Lo que estás preguntando ("más control que root") no es posible, ¡ni siquiera una cosa!
Andy
@mchid Entonces, ¿lo que realmente quiere hacer es cambiar el nombre del usuario root actual a mchid, crear un nuevo usuario llamado root y hacer que apt-get et al utilicen su nuevo usuario no root?
Odalrick
En algunos sistemas, rootno tiene permiso para acceder al hardware directamente. Si deshabilita la carga de los módulos del núcleo, puede mantener la raíz bloqueada fuera del control total sobre el hardware ( /dev/memy cosas así). No es realmente relevante para los permisos del sistema de archivos, ya que no usaría un apt-get que hablara directamente con su controlador SATA o NVMe ... Pero técnicamente, hay un estado de "más permisos que root", y se llama modo kernel. : P
Peter Cordes
26

Si solo desea evitar que los archivos o directorios se cambien / eliminen, simplemente establezca la marca inmutable en ellos.

chattr +i <file>

Ni siquiera root podrá hacerles nada a menos que se elimine la bandera. También es posible usar el sistema contenedor / espacio de nombres para evitar el acceso a la raíz, pero eso parece excesivo para lo que necesita.

CR.
fuente
11
Pero root puede eliminar la bandera.
sebasth
10
apt, como casi todo, no usará chattr para eliminar esa bandera.
CR.
13
@sebasth: Correcto, pero los scripts de instalación de Apt, dpkg y por paquete no alterarán (normalmente) los atributos del archivo. En cambio, simplemente fallarán y se quejarán cuando intenten alterar los archivos con el indicador inmutable.
David Foerster
44
@TripeHound Entonces, ¿el OP quiere apt-gettener éxito en reemplazar el archivo, sin embargo, tener ese archivo intacto? Eso es algo contradictorio, me atrevo a decir.
Dmitry Grigoryev
3
@DmitryGrigoryev Es suena como que quieren apt-geta pensar que tuvo éxito, pero dejando uno o más archivos sin cambios. No dicen qué archivos o por qué, pero como usted dice, algo contradictorio y propenso a "comportamientos extraños" en el futuro.
TripeHound
9

  • En lugar de tener un super-super-usuario, puede limitar la raíz. vea ¿Cuáles son las diferentes formas de establecer permisos de archivo, etc. en gnu / linux

  • También hay AppArmor y SELinux.

  • Y / o configure sudo, para que no otorgue todos los privilegios de root. Puede configurarlo para que un usuario solo pueda ejecutar comandos previamente acordados, con argumentos previamente acordados.

  • También puede usar la virtualización para restringir la raíz:

    • cgroups, espacios de nombres, chroot, etc. (Docker hace esto)
    • Xen
    • Virtualbox

  • Ver también etckeeper: esta revisión de herramienta controla el /etcdirectorio y se sincroniza con apt. De forma predeterminada, no es seguro, una instalación maliciosa podría sabotearlo, pero también podría hacer que empuje los cambios a un repositorio de copia de seguridad con paredes de fuego.

  • Uso del control de revisión en general, con un repositorio de respaldo con paredes cortafuegos. Esto ayuda con la corrupción accidental e intencional y la falla del hardware.

Los repositorios de respaldo con firewall pueden estar en una máquina diferente, en Internet o en una máquina virtual diferente (o host de la máquina virtual).

ctrl-alt-delor
fuente
8

Para software como APT , que en funcionamiento normal requiere acceso a casi todo el sistema, la restricción es problemática. Incluso si evita que acceda a ciertas partes del sistema, lo más probable es que existan posibilidades más que suficientes para que un distribuidor malicioso pueda evitarlo. Por ejemplo, reemplazando una biblioteca o simplemente un binario o agregando un cambio de configuración malicioso, que la raíz sin restricciones va a usar eventualmente.

Dependiendo de cuánto colocaría restricciones, se puede esperar que algunos scripts de instalación se rompan.

Para conocer las formas de restringir las aplicaciones y los usuarios, puede escribir una AppArmor o una política de SELinux. Dicha política sería La más compatible depende de su distribución: las basadas en Debian tienen una mejor compatibilidad con AppArmor, mientras que las distribuciones basadas en Fedora / RHEL habilitan SELinux por defecto.

Tanto AppArmor como SELinux funcionan en políticas de listas blancas , que contienen reglas para permitir (o denegar) acciones específicas. Las políticas se aplican a un proceso en exec , de manera similar, los usuarios pueden ser restringidos cuando una política se aplica a sus procesos al iniciar sesión. No se puede eludir una política bien pensada (si no se consideran los errores del kernel). El proceso confinado que se ejecuta como root (uid 0) está restringido por la política configurada y no puede cambiarlo a menos que se permita explícitamente en la política.

El lenguaje de políticas de AppArmor define una regla de denegación , que se puede usar para crear una política de lista negra . Un buen lugar para comenzar con AppArmor son las páginas de manual de AppArmor , el wiki y la configuración existente en su distribución /etc/apparmor.d/.

Se proporciona mucho material de administración y desarrollo de SELinux en la wiki de SELinux . La política de referencia de SELinux está alojada en github.

sebasth
fuente
7

No puedo creer que nadie haya mencionado la posibilidad de fijar ...

Hace un par de años, Microsoft lanzó un parche que impedía que las máquinas con Windows 10 hablaran con nuestros viejos controladores de dominio Samba NT4. Cuando se encontró el problema, fijamos el paquete Samba para que se mantuviera en la versión actual y aptaún funcionara correctamente.

Un tutorial completo de Debian explica bien el proceso:

En /etc/apt/preferences(o un nuevo archivo debajo /etc/apt/preferences.d/), agregue texto para especificar qué paquete y versión:

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

Consulte la documentación para conocer la sintaxis exacta, pero esta es la forma rápida y sucia de que fijamos una versión del paquete. Root podría omitirlo, como siempre puede hacer root, pero esto resuelve el problema de los administradores de paquetes que intentan actualizar automáticamente los paquetes en usted.

NOTA: esta respuesta supone que tiene un problema XY

El canadiense Luke REINSTATE MONICA
fuente
Yo mismo he respondido a una serie de problemas XY en askubuntu. Sin embargo, apt es solo un ejemplo y es lo que me llevó a la idea. Estoy más interesado en el aspecto "poder-corrompe-y-poder-corrompe-absolutamente" absolutamente todo el asunto. El poder completo y absoluto sobre mi propio sistema es lo que me llevó a Linux en primer lugar. Darme cuenta de que mi poder no siempre es absoluto sobre la raíz es algo inquietante; La idea del poder absoluto es atractiva.
mchid
Además, supongo que es un poco un problema XY, pero Y aquí es "¿cómo puedo negar el permiso de root cuando root es el superusuario?"
mchid
1
@mchid no se trata de negar permisos a root, sino de negar algo a un programa que se ejecuta como root.
John Keates
6

En realidad es bastante simple.

Root es tu "super super usuario"

Cree una cuenta llamada "admin" y dele todos los permisos de root, excepto el que no desea.

Luego cree un usuario llamado bob y déjelo "convertirse en administrador". Mediante el uso de su o incluso sudo.

Ahora tiene un usuario normal (bob), un superusuario que puede hacer cosas de administrador (admin) y un superusuario (root).

Si desea cambiar el nombre "raíz" a otra cosa, incluso puede hacerlo. Técnicamente solo importa la identificación de usuario (0).

coteyr
fuente
Si tuviera un usuario normal (bob), un súper usuario que pueda hacer cosas de administrador (admin) y un súper usuario (root), la raíz aún no estaría haciendo todas las cosas de administrador con los procesos en segundo plano, cronjobs y otras cosas como id de usuario (0)?
mchid
no si no quieres que lo hagan. La mayoría de los servicios le permiten elegir qué usuario hace el trabajo. Puede configurarlo para que el usuario administrador sea el que ejecute los procesos. Hay algunas excepciones, pero no muchas.
coteyr
¿No tendría que pasar y configurar todos esos procesos individualmente?
mchid
3
Eso es lo que sucede cuando intentas romper las convenciones estándar. Creo que necesita comprender mejor los cómo y los porqués de los sistemas de permisos en un entorno * nix.
Shauna
2
Estoy de acuerdo con Shauna, parece que te falta una comprensión fundamental del sistema de permisos * nix. Es muy poderoso, pero no se parece en nada a Windows.
coteyr
3

Si lo que desea es simplemente evitar que se instalen archivos específicos, entonces restringir los permisos de root no es la forma de hacerlo. Vale la pena señalar también que las respuestas convencionales (archivos inmutables o LSM) no funcionarán para su caso de uso particular, ya que APT (y la mayoría de los otros administradores de paquetes) se rescatarán si no pueden instalar archivos.

La verdadera pregunta que quieres hacerte es:

¿Hay alguna manera de evitar que APT instale archivos específicos?

Eso es algo completamente diferente de lo que estás pidiendo en múltiples niveles.

Ahora, en cuanto a esa pregunta, no estoy 100% seguro, pero sé que varios otros administradores de paquetes tienen opciones para evitar la instalación de archivos específicos (por ejemplo, el sistema Portage de Gentoo tiene la opción INSTALL_MASK=, que en realidad acepta shell estilo de patrones coincidentes de cosas para no instalar). Estaría más que dispuesto a apostar que dicha opción existe para APT (o posiblemente dpkg en sí).

Austin Hemmelgarn
fuente
Realmente, "¿Hay alguna manera de evitar que APT instale archivos específicos?" no es mi pregunta esto es solo un ejemplo y lo que me hizo pensar en la pregunta. El nuevo firefox se envía con complementos e instala estos archivos incluso después de que el usuario los elimine con nuevas actualizaciones. Este no es realmente el problema; Esto es lo que me hizo darme cuenta de que quiero aún más control sobre mi sistema. Sin embargo, aprecio su lógica aquí, ya que he respondido algunas preguntas de esta manera, así que gracias por el aporte.
mchid
dpkg-divert hace esto: unix.stackexchange.com/a/157896/70847
mchid
1

Ponga una copia de seguridad en un lugar seguro. Después de cualquier instalación / actualización, reemplace inmediatamente los archivos específicos de esa copia de seguridad. Por lo tanto, no hay errores para arruinar la instalación, pero aún así recupera los archivos que desea conservar.

WGroleau
fuente
1

Trabajar desde una unidad montada

Tenga en cuenta que esta es principalmente una respuesta conceptual, pero creo que debería funcionar y estar en espíritu con lo que desea lograr.

Deje que el sistema X sea su sistema de trabajo, y el sistema Y, otro sistema que usted controle.

  1. Montar un directorio desde Y como una unidad en X
  2. Configure los derechos de tal manera que el usuario raíz de X tenga derechos sobre todo en esta unidad montada, con algunas excepciones.

Ahora tiene su 'raíz de trabajo' que puede hacer casi todo, y tiene su 'superraíz', la cuenta raíz real del sistema Y, que realmente puede hacer todo.

Dennis Jaheruddin
fuente
Sin embargo, me gusta la idea, me gustaría hacer esto en un sistema en ejecución.
mchid
1

Podrías ejecutar un hipervisor de tipo 1 como el hipervisor Xen y tener eso alojando tu sistema operativo normal como invitado virtualizado. El hipervisor controla el SO huésped virtual a un nivel "más profundo" que el root porque tiene control sobre el hardware (virtual) en el que se ejecuta el SO huésped.

Puede programar el hipervisor para manipular el sistema operativo invitado de varias maneras, incluido el cambio de permisos, la creación y aplicación de copias de seguridad, el enganche de ciertos cambios o instrucciones en el sistema operativo invitado para inyectar funcionalidad adicional, validación, etc. Esa sería una forma válida y potencialmente útil. implementar un sistema de tipo unix con un "usuario" (en realidad una función del hipervisor) para "hacer cosas que incluso el root no puede hacer"

Aunque creo que este enfoque es probablemente exagerado

Nathan Smith
fuente
¿Cómo impide un hipervisor que un usuario con permiso de root haga lo que desee en una máquina virtual invitada?
fpmurphy
Esta respuesta comienza bien, pero luego se desvía gramaticalmente (luego está leyendo al revés, o al menos ambigüedades). Hice una solución
ctrl-alt-delor
1
@ fpmurphy1 un hipervisor puede enganchar llamadas del sistema, aplicar políticas, etc. para imponer restricciones arbitrarias al usuario root o cualquier otra parte del SO huésped. Tal vez mi respuesta no sea buena porque esto es demasiado trabajo a menos que tenga algún caso de uso empresarial real o algo así ...
Nathan Smith
@ ctrl-alt-delor Gracias por su solución, pero no creo que la gramática fuera el problema. Sin embargo, aclaré lo que quería decir, y agradezco los comentarios de que mis pensamientos no estaban claros al principio
Nathan Smith
1
@ fpmurphy1 dentro del invitado tienes root completo. Sin embargo, no es la misma raíz que la raíz en el host. Por lo tanto, es una raíz menor que la raíz del host. Docker permitirá que las cosas estén más integradas, pero aún impondrá restricciones a la raíz.
ctrl-alt-delor
1

Eche un vistazo a cgroups y espacios de nombres de Linux como un método alternativo para lograr este tipo de objetivo, así como herramientas basadas en ellos como Docker y lxd .

Estas herramientas le permiten, entre otras cosas, limitar qué partes del sistema de archivos puede ver un proceso que se ejecuta como "raíz", limitar qué procesos son visibles para él y proporcionar solo ciertas capacidades al usuario "raíz".

smw
fuente
0

DESINSTALAR sudo

¿Qué tal la desinstalación sudoy el enlace simbólico /bin/sua /bin/false? Combine eso con asegurarse de que rootno pueda iniciar sesión a través de sshy que haya bloqueado el sistema.

Eso convierte rootal Super * Super Usuario, y todos los demás están subordinados a eso.

Para los archivos reemplazados durante las actualizaciones, simplemente no realice ninguna actualización. De manera más realista, cambie los permisos de los archivos de 440o 444para que no puedan ser escritos. O póngalos en un repositorio de git para que si se sobrescriben, se puedan revertir.

usuario176717
fuente
Verá, todavía quiero hacer actualizaciones y todavía quiero que root haga casi todas las cosas que normalmente hace root. Sin embargo, quiero poder decir a la raíz "oye, no hagas eso" o "no, no puedes hacer eso" como una autoridad parental podría hacerle a una descendencia. Tal como está ahora, Root es como la autoridad de los padres en mi sistema y todos los niños pequeños dicen "madre, ¿puedo?" cuando usan sudo. Esto esta bien. Sin embargo, casi todas las personas en este planeta son descendientes de alguien. Parece que algunas respuestas aquí son como un niño estaría en antes de conciencia de sí mismo cuando no se dan cuenta
mchid
. . . que la abuela y el abuelo son las madres y los padres de mamá y papá. Me gustaría pedirle al abuelo que venga a vivir a mi sistema porque, en este momento, la raíz es el papá de la casa y el abuelo puede decirle a papá qué hacer porque el abuelo es el padre de papá :)
mchid
Parece que ha agregado demasiadas personas con poderes de sudo. Ajuste el sudoersarchivo para que solo los usuarios seleccionados puedan sudo a los comandos preseleccionados.
user176717
Solo tengo dos usuarios en el archivo sudoers, incluido root. Estaba tratando de usar un símil para explicar cómo algunas personas parecen no entender mi pregunta y qué me gustaría lograr.
mchid
Parece que la gente siente que no puede haber ningún usuario más alto que root de la misma manera que un niño muy pequeño siente que su mamá y su papá no pueden tener padres. Además, no voté en contra.
mchid