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.

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.

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.

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.

• 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).

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.

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

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).

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í).

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.

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.

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

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".

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.