¿Por qué se aplica la seguridad de la raíz pero normalmente no se protege a $ HOME?

Voy a estar en desacuerdo con las respuestas que dicen que la edad del modelo de seguridad de Unix o el entorno en el que se desarrolló es culpa. No creo que ese sea el caso porque existen mecanismos para manejar esto.

  

El sistema de permisos de root tiene sentido, pero en los sistemas de escritorio, parece que protege los datos incorrectos.

Los permisos del superusuario existen para proteger el sistema de sus usuarios. Los permisos en las cuentas de usuario están ahí para proteger la cuenta de otras cuentas no root.

Al ejecutar un programa, le das permisos para hacer cosas con tu UID. Debido a que su UID tiene acceso completo a su directorio de inicio, de forma transitoria le ha dado al programa el mismo acceso. Al igual que el superusuario tiene acceso para realizar cambios en los archivos del sistema que necesitan protección contra comportamientos maliciosos (contraseñas, configuración, binarios), es posible que tenga datos en su directorio de inicio que necesiten el mismo tipo de protección.

El principio de privilegio mínimo dice que no debe dar más acceso del que es absolutamente necesario. El proceso de decisión para ejecutar cualquier programa debe ser el mismo con respecto a sus archivos que con los archivos del sistema. Si no da un fragmento de código en el que no confía en el uso no restringido de la cuenta de superusuario para proteger el sistema, no se le debe otorgar un uso ilimitado de su cuenta para proteger sus datos.

  

¿No hay forma de evitar que ocurra un código malicioso en $ HOME? ¿Y por qué a nadie le importa?

Unix no ofrece permisos granulares por la misma razón no hay un protector de hoja alrededor del comando rm : los permisos no existen para proteger a los usuarios de ellos mismos.

La forma de evitar que los códigos maliciosos dañen los archivos en su directorio de inicio es no ejecutarlo con su cuenta. Cree un usuario independiente que no tenga permisos especiales y ejecute el código bajo ese UID hasta que haya determinado si puede o no confiar en él.

Hay otras formas de hacerlo, como las cárceles chrooteadas, pero configurarlas requiere más trabajo y escapar de ellas ya no es el desafío que alguna vez fue.

Porque el modelo de seguridad basado en UNIX tiene 50 años.

UNIX subraya la mayoría de los sistemas operativos extendidos, e incluso la gran excepción de Windows ha sido influenciada por ella más de lo que parece. Se deriva de una época en que las computadoras eran máquinas grandes, caras y lentas utilizadas exclusivamente por especialistas arcanos.

En ese momento, los usuarios simplemente no tenían una extensa colección de datos personales en cualquier , no en su servidor de la universidad, no en su computadora personal (y ciertamente no en su teléfono móvil). Los datos que variaban de un usuario a otro eran típicamente datos de entrada y salida de procesos de computación científica; perderlos podría constituir una pérdida, pero en gran medida podría compensarse con una nueva cálculo, sin duda nada como las consecuencias de las fugas de datos actuales.

Nadie habría tenido su diario, información bancaria o fotos de desnudos en una computadora, por lo que protegerlos de acceso malicioso no era algo que tuviera una alta prioridad, de hecho, la mayoría de los estudiantes universitarios en los años 70 probablemente hubiera sido emocionado si otros hubieran mostrado interés en sus datos de investigación. Por lo tanto, la prevención de la pérdida de datos se consideró la máxima prioridad en la seguridad informática, y eso se garantiza de manera adecuada mediante copias de seguridad regulares en lugar de control de acceso.

Esta es una observación muy astuta. Sí, el malware que se ejecuta como su usuario puede dañar / destruir / modificar datos en su directorio de inicio. Sí, la separación de usuarios en sistemas de un solo usuario es menos útil que en los servidores. Sin embargo, todavía hay algunas cosas que solo el usuario root (o equivalente) puede hacer:

• Instale un rootkit en el kernel.
• Modifique el cargador de arranque para que contenga una puerta trasera antigua para la persistencia.
• Borre todos los bloques del disco duro, haciendo que sus datos sean irrecuperables.

Honestamente, encuentro que la separación de privilegios en las estaciones de trabajo es la más útil para proteger la estación de trabajo de su enemigo más grande: yo. Hace que sea más difícil arruinar y romper mi sistema.

Además, siempre puede configurar un trabajo cron como raíz que haga una copia de seguridad de su directorio de inicio (con, por ejemplo, rsnapshot ) y lo almacene de tal manera que su usuario no pueda escribirlo. Eso sería un cierto nivel de protección en la situación que describe.

Xkcd obligatorio

El diseño original de la seguridad de Unix / Linux era proteger a un usuario de otros usuarios, y los archivos del sistema de los usuarios. Recuerde que hace 30 o 40 años, la mayoría de los sistemas Unix eran configuraciones multiusuario con muchas personas que inician sesión en la misma máquina al mismo tiempo. Estos sistemas cuestan decenas de miles de dólares, y era extremadamente raro tener su propia máquina personal, por lo que la máquina se compartió en un entorno de inicio de sesión de múltiples usuarios.

El diseño nunca pretendió proteger los archivos de un usuario o de un código malicioso, solo para proteger a los usuarios de otros usuarios, a los usuarios de modificar el sistema subyacente ya los usuarios de utilizar demasiados recursos del sistema. En nuestra era actual, donde cada uno tiene su propia computadora, el diseño se ha traducido (en su mayoría) en máquinas de un solo usuario que protegen un proceso para no acaparar demasiados recursos del sistema.

Por esta razón, un programa ejecutado por el usuario tiene acceso a cualquier archivo que el usuario posee. No hay ningún concepto de acceso adicional en los archivos propios de un usuario. En otras palabras, un proceso ejecutado como usuario A tiene acceso para leer, modificar y eliminar todos los archivos que pertenecen al usuario A. Esto incluye (como se nota) los archivos de inicio automático.

Un enfoque más moderno puede implicar alguna forma de control adicional sobre ciertos archivos. Algo así como la "re-autenticación requerida" para acceder a estos archivos, o tal vez alguna forma de protección adicional de los archivos de uno de los programas desde los archivos de otros programas. AFAIK no hay (actualmente) nada como esto en el mundo de escritorio de Linux. ¿Me corrige si me equivoco?

  

¿No hay forma de evitar que ocurra un código malicioso en $ HOME?

Para responder a esta pregunta, lo que hacen algunas instalaciones es hacer uso del marco de seguridad existente al hacer que un usuario ejecute específicamente el programa. Los programas tendrán una opción de configuración para especificar qué usuario deben estar ejecutando. Por ejemplo, mi instalación de PostgreSQL tiene los archivos de base de datos propiedad del usuario postgres , y el servidor de base de datos se ejecuta como postgres . Para los comandos administrativos de PostgreSQL, cambiaría los usuarios a postgres . OpenVPN también tiene la opción de cambiar a un usuario sin privacidad una vez que se hace usando los poderes administrativos de la raíz (para agregar interfaces de red, etc.). Las instalaciones pueden tener un usuario llamado nobody específicamente para este propósito. De esta manera, los exploits en PostgreSQL o OpenVPN no necesariamente llevan al compromiso de $HOME .

Otra opción es usar algo como SELinux y especificar exactamente a qué archivos y otros recursos tiene acceso cada programa. De esta manera, incluso puede negar que un programa que se ejecuta como root toque sus archivos en $HOME . Escribir una política detallada de SELinux que especifique que cada programa sea tedioso, pero creo que algunas distribuciones como Fedora van a la mitad y tienen políticas definidas que solo agregan restricciones adicionales a los programas que se enfrentan a la red.

Para responder a la segunda parte de su pregunta: existen mecanismos de sandbox, pero no están habilitados de forma predeterminada en la mayoría de las distribuciones de Linux.

Una muy antigua y complicada es selinux. Un enfoque más reciente y más fácil de usar es apparmor. Lo más útil para el uso personal (los sistemas de apparmor y similares se usan principalmente para proteger a los demonios) es firejail , que aísla los procesos en su propia cárcel.

Un Firefox, por ejemplo, solo puede escribir su directorio de perfil y el directorio de Descargas. Por otro lado, no podrá cargar imágenes si no las coloca en el directorio de descargas. Pero esto es por diseño de tal caja de arena. Un programa podría eliminar sus imágenes o subirlas a sitios aleatorios, por lo que la cárcel lo impide.

Usar FireJail es fácil. Lo instalas y para los programas que ya tienen un perfil (busca en /etc/firejail ) puedes hacerlo (como root) ln -s /usr/bin/firejail /usr/local/bin/firefox . Si no es root o desea usar argumentos de línea de comando para firejail (por ejemplo, una ruta personalizada a los archivos de perfil) puede ejecutar firejail firefox .

Los sistemas como snap también desean agregar mecanismos de espacio aislado, para que pueda ejecutar un programa no confiable instalado desde un repositorio de snap aleatorio sin demasiadas consecuencias. Teniendo en cuenta todos estos mecanismos, los programas que no son de confianza aún pueden hacer cosas como enviar spam o ser parte de un ataque dDoS.

La presunción de que se están protegiendo los datos incorrectos es falsa.

La protección de root activities sí protege sus fotos de vacaciones de 2011. Y las mías y las de sus hermanos y las de todos los demás que usan la computadora.

Incluso si implementó un sistema operativo con un esquema que protegía la cuenta doméstica al solicitar una contraseña cada vez que una aplicación intentaba acceder a un archivo y eliminaba la protección de la contraseña de root, no la usaría porque sería peor para esas fotos de vacaciones.

Si mi hermano compromete la funcionalidad del sistema central en la computadora de mi hogar, entonces las fotos de mis vacaciones se eliminan, se ven afectadas por el rescate, o lo que sea, a pesar de las protecciones de su directorio principal, ya que el sistema en sí está comprometido y puede sortear cualquier nivel de usuario. restricciones que implementaste.

Y la mayoría de las personas se sentirían muy molestas si tuvieran que ingresar una contraseña cada vez que eligieran File -> Open en su procesador de textos.

Además, hemos tenido el problema de que el control de acceso se solicita con demasiada frecuencia en las computadoras de la casa. Cuando Microsoft lanzó por primera vez su UAC (para lo cual ni siquiera necesita ingresar una contraseña si usa la cuenta principal ... todo lo que necesita hacer es presionar un botón ), surgió Mucho y la gente se quejó lo suficiente de los 0,5 segundos de su vida desperdiciados 20 veces por día que Microsoft lo cambió. Ahora bien, este no era el tipo de protección del que está hablando, pero nos muestra que si las personas no están dispuestas a hacer clic en un botón de seguridad unas cuantas docenas de veces por día para la seguridad del sistema de Microsoft, no querrán hacer clic. (o, peor aún, escriba una contraseña) para lo que se implementa para proteger sus fotos de la aplicación aleatoria que acaba de ejecutar.

Entonces la respuesta básica es:

1. Proteger la raíz protege tus fotos personales.
2. La gente se queja de que ese tipo de autenticación se solicite con demasiada frecuencia.

Un punto clave para asegurar la raíz / kernel es integridad forense . En el caso de que el dominio que contiene sus datos valiosos (usuario de escritorio con documentos privados y tokens de autenticación web, servidor de desarrollo con código / recursos confidenciales, servidor de aplicación web con base de datos de usuarios, etc.) se vea comprometido, todavía tiene un dominio sin compromisos desde la cual evaluar el compromiso, determinar qué sucedió, desarrollar un plan para defenderse contra lo mismo que está sucediendo nuevamente, etc.

Otras respuestas miran por qué * nix es como es.

Pero vale la pena señalar que hay posibilidades de hacer un poco más que la configuración "lista para usar", para proteger el directorio, los scripts y los archivos de inicio del usuario.

Las más modernas * nix admiten POSIX o variantes de ACL, que se pueden configurar para agregar el tipo de control de acceso granular que el OP está buscando. Tiene que configurarlos manualmente, y no intentan distinguir el acceso en ninguna otra base que no sea la cuenta de usuario / grupo que está actuando. Pero una vez configurado, puede ser muy específico qué cuentas pueden realizar qué acciones en los archivos y obtener al menos algún control adicional al obligar a los comandos a usar cuentas limitadas para ciertos comandos o archivos, en lugar de una cuenta de usuario para todo. Sin embargo, tendrá un límite de practicidad bastante estricto.

Tales privilegios no existen porque son inconvenientes.

El objetivo de los permisos, en general, es evitar acciones no deseadas. El tipo de acciones que root puede hacer es mucho más insidioso. Una aplicación de ransomware a nivel de usuario puede cifrar sus archivos, pero no puede ocultar el hecho de que lo están haciendo. Cuando encuentra un archivo encriptado, se abre de la forma habitual y revela que se ha cifrado. Con un ransomware de nivel raíz, puede secuestrar todo su sistema de archivos y crear la ilusión de que los archivos no están cifrados hasta el último momento, luego olvide la clave y bam . Todos sus archivos se vuelven inaccesibles al mismo tiempo.

Ahora, obviamente, ahora no iniciamos sesión como root. Usamos sudo. Esta es una forma de privilegio basado en roles. No tiene privilegios de root hasta que asuma el rol de "un usuario que realiza tareas administrativas". Luego ganas esos privilegios, hasta que finalices el comando.

Un podría crear roles detallados que tengan acceso a diferentes carpetas. Quizás desee que las "fotos de vacaciones" se lean solo a menos que ingrese en el rol de "agregar / editar fotos". Esto sería poderoso, pero exigente. Como Aaron mencionó, el UAC de Windows fue ampliamente criticado por perder preciosos segundos pidiendo permiso en lugar de simplemente hacer cosas. Su computadora necesitaría pedir permiso con más frecuencia si tuviera que cambiar de roles para proteger sus datos. En general, los usuarios no han encontrado que esto valga la pena, por lo que no es compatible.

(Si estaba interesado en tales capacidades y estaba dispuesto a usar sudo para realizarlas, podría crear una partición separada que podría montarse ro o rw, dependiendo de lo que quiera hacer, y almacenar sus fotos allí). / p>

Una de las tareas más difíciles de tratar en estos casos es la granularidad de los roles. Si el usuario ingresa un rol u otro, eso es bastante fácil de manejar. Sin embargo, es más difícil manejar el caso en el que una aplicación en particular necesita ingresar ese rol. Tal vez Firefox no tenga permiso para escribir en tus fotos, pero GIMP puede hacerlo. Esto es complicado porque donde hay límites, no se puede tener una integración perfecta y coherente. ¿Qué sucede si Firefox aprovecha un complemento de GIMP para editar fotos? La única forma de evitar que Firefox lo haga es evitar que hable con GIMP.

Supongo que tienes algo de experiencia con Windows. ¿Alguna vez te preguntaste por qué la pantalla se oscurece cuando aparece el UAC? En realidad, es no para la confirmación visual de que estás haciendo algo especial. Es mucho más importante que eso. Las ventanas sobre la parte atenuada forman parte de una pantalla diferente , aisladas de las ventanas debajo. ¿Porque es esto importante? Bueno, resulta que cualquier ventana en una pantalla puede manipular cualquier otra ventana en esa misma pantalla. Si el UAC apareció en la misma pantalla que el programa de instalación y solicita permisos, el instalador podría literalmente obtener un identificador de la ventana de UAC y hacer clic en Aceptar por usted . Eso ciertamente anularía el propósito de tal pronta. La solución es que el UAC se proporciona en una pantalla diferente , por lo que ninguna otra aplicación puede hacer clic en Aceptar por sí sola. La única forma de hacer clic en Aceptar es si el usuario mueve el mouse y lo pulsa. El oscurecimiento está realmente allí para mostrarle que no puede interactuar con ninguna de las ventanas debajo mientras la pantalla de UAC tiene el control del teclado / mouse.

Así que ese es el nivel de esfuerzo que se debe pasar por el aislamiento. No es fácil. De hecho, es bastante difícil que tenga sentido que usted proteja sus datos clave al tener cuentas de múltiples usuarios y que cada uno tenga un acceso diferente a los datos. Entonces podrías usar la capacidad de cambiar de usuario para cambiar entre ellos. Esto proporcionaría el tipo de aislamiento que necesita para hacer privilegios decentes basados en roles.

Unix no es realmente un sistema de escritorio. Es un sistema que se ejecuta en una computadora grande que cuesta aproximadamente tanto como una casa ubicada en algún lugar del sótano de su universidad. Usted, como alguien que no puede costear su propia computadora, tiene que compartirla con otras dos mil personas, y con varias docenas de usuarios simultáneamente, para el caso.

Incidencialmente, en la actualidad también puede también ejecutar un sistema similar a Unix en su computadora de escritorio o en una SoC del tamaño de una tarjeta de crédito que cuesta $ 20.

En principio, sin embargo, Unix no está diseñado para usuarios individuales. El único usuario no es importante. Lo que está en su directorio personal es su problema, pero lo que root puede hacer es el problema de todos. Por lo tanto, solo las pocas tareas que realmente requieren que trabaje como root se deben hacer con ese usuario, y preferiblemente (para limitar la ventana de tiempo durante la cual puede causar daño) no al iniciar sesión con esa cuenta, sino explícitamente usando sudo para los comandos individuales que lo requieren. También hay mucha religión en eso, por lo que algunos distribuidores son tan arrogantes que te amenazan cuando escribes su en lugar de sudo para cada uno de los 10 diferentes comandos apt que tienes que ejecutar Para instalar alguna cosa mezquina. Este incidente será reportado , bueno, te diré qué, jodas tu informe. Algunas personas realmente saben cómo molestar a los demás.

Para que puedas borrar todas tus fotos personales sin ser root . Está bien. El malware puede borrar todas las cosas en su directorio de inicio, eso es correcto. Puede negar el servicio llenando su disco hasta que se alcance su cuota de usuario, eso es correcto. Pero desde el punto de vista del sistema, ese es solo tu problema, y a nadie más le importa. Ningún otro usuario está (en principio) afectado.

Ahora, el problema con un sistema de usuario único (o pocos) moderno es que el modelo de seguridad lógica bivalente es bastante inaplicable, al igual que la idea de "hay cientos de usuarios".

Desafortunadamente, es muy difícil encontrar algo mejor. Mire a Windows si desea ver cómo no robar una idea (realmente lograron empeorar un mal enfoque).

Algunos navegadores web y sistemas operativos de teléfono (o TV inteligente) intentan (y fallan) proporcionar algo mejor, y el Linux moderno también tiene un sistema más detallado (pero no sabría cómo configurarlo correctamente) sin pasar semanas de mi tiempo).

El problema es que el modelo de seguridad bivalente asume que las aplicaciones normales no requieren ningún privilegio (lo cual es incorrecto porque algunas cosas que en su mayoría son inofensivas sí requieren privilegios) mientras que las aplicaciones no normales requieren acceso completo al sistema informático (que también es mal, casi ningún programa necesita acceso completo, nunca).

Por otra parte, incluso los modelos de seguridad más finos (que aún son bastante toscos) suponen erróneamente que si una aplicación solicita un conjunto de privilegios, realmente necesita ese conjunto completo y el usuario se siente cómodo con otorgarlo.

Según mi conocimiento, no hay ningún sistema en el que una aplicación pueda solicitar los privilegios A, B y C, y el usuario puede aceptar otorgar A (pero no B y C), y la aplicación puede consultar qué privilegios se le dio y decidir si es capaz de realizar la tarea solicitada o no.

Por lo tanto, generalmente tiene la opción de otorgar la aplicación XYZ "almacenar datos en almacén permanente" (con lo que quizás esté de acuerdo) y también permitir "acceder a mi ubicación" y "acceder a mi datos personales "o" instalar el controlador del sistema "(con lo que no está de acuerdo), o bien, no puede ejecutar el programa.
O bien, puede permitir que el programa XYZ "realice cambios en su computadora", lo que sea que eso signifique, o puede elegir no ejecutarlo. Y, tienes que confirmarlo de nuevo cada vez. Lo cual, ser honesto, realmente apesta desde la perspectiva del usuario.

  

¿No hay forma de evitar que ocurra un código malicioso en $ HOME?

Suponiendo que tiene /home como un punto de montaje individual, en su propia partición, entonces puede simplemente editar /etc/fstab y agregar el indicador noexec a las opciones de montaje. Esto deshabilita toda la ejecución del código en esa partición, con la desventaja de que el código dentro de ~/bin (como algunas instalaciones por usuario pueden crearlo) tampoco se ejecutará más. sin embargo, esto no detendrá un ejecutable ubicado en otra parte del sistema de archivos para eliminar /home .

SE Linux es un sistema de seguridad completo que se puede aislar bien, mientras que AppArmor es solo para el aislamiento de aplicaciones. El Linux subyacente de Android lo presenta, desde v 5.0 algo. En Windows, recientemente introdujeron "carpetas protegidas", que es bastante similar (una copia completa). Aquí el inconveniente es que cuando se instala algo nuevo manualmente, a menudo hay que etiquetar y / o establecer los indicadores adecuados para permitirlo, mientras que el contexto en el que se ejecuta algo es más importante allí. la gente a menudo sugiere deshabilitarlo, simplemente porque no entienden cómo manejarlo. Bueno, este no es exactamente el punto de elegir una distribución SE Linux para un despliegue.

Me sorprende que nadie haya mencionado lo siguiente:

Una de las razones principales para no iniciar sesión en una máquina de escritorio como root es que muchas actividades cambiarán la propiedad de los archivos para convertirse en root. Esto generalmente significa que los usuarios "normales" no podrán ejecutar muchas aplicaciones porque no pueden leer el archivo de configuración predeterminado que fue creado por la raíz.

Una de las razones principales para no iniciar sesión en una máquina servidor como root es que, desde una perspectiva de auditoría / trazabilidad, es mejor tener a alguien que inicie sesión como él mismo y luego ejecutar comandos como root para que exista un registro auditable que indique que 'user1' inició sesión y luego cambió a raíz en lugar de saber que 'root' inició sesión desde la dirección IP 10.2.1.2, que puede ser un terminal genérico disponible para muchas personas. En una máquina servidor, es más común tener acceso limitado de sudo a muchos comandos para intentar mantener las acciones ejecutadas por un administrador más auditables y rastreables.

Al igual que con todas las actividades de raíz, puede hacer lo que quiera; solo recuerda que cuanto más haces, más grande es el arma apuntando a tu pie y solo se necesita un comando incorrecto para apretar el gatillo.

rm -rf {uninitializedVariable}/*