Evita que las aplicaciones tengan acceso completo a los archivos de usuario

Navega tus respuestas
4

Las aplicaciones no deben tener acceso a los datos de otras aplicaciones ni a los datos privados del usuario, a menos que el usuario lo permita. ¿No es esto una necesidad obvia? Pero cada programa que lanzamos tiene acceso completo a nuestro directorio $ HOME, a nuestro micrófono y cámara. La mayoría de los usuarios ni siquiera notarán si (por ejemplo) Skype comienza a enviar a algún lugar sus archivos privados o transmite sonido desde su micrófono.

Estoy buscando maneras de solucionar este problema. Siéntase libre de sugerir cualquier cosa, incluso si su método implica escribir políticas SELinux, módulos LSM, parches del kernel, cambiar a otro sistema operativo similar a UNIX.

Aquí hay algunas ideas que tuve y las razones por las que las rechacé:

  1. Creamos nuevos usuarios de Unix para todas las aplicaciones que no son de confianza. Usamos el bit SUID para hacer que la aplicación siempre se ejecute como usuario. Malo. Porque necesitamos poner en una lista negra todas las aplicaciones en las que no confiamos y cada aplicación nueva que instalemos. Toneladas de trabajo, fáciles de perder algo. También los binarios pueden perder el indicador SUID cuando actualizamos / reinstalamos la aplicación. Además, hay un problema con los procesos secundarios: en teoría, las aplicaciones que no tienen algún permiso pueden usar otras aplicaciones para lograr su objetivo. Y si no usamos SUID, será difícil recordar que necesitamos usar "su" para iniciar todas las aplicaciones que no sean de confianza.
  2. Usamos la transición del dominio SELinux para confinar aplicaciones no confiables. También malo. El mismo problema que con el # 1. Necesitamos escribir / actualizar / inyectar políticas SELinux para cada aplicación en la que no confiamos. Quiero que las aplicaciones no tengan acceso especial por defecto, no acceso completo.
  3. Creamos nuevos usuarios unix "confiables" para aplicaciones confiables. Podemos usar grupos para implementar varias categorías de datos privados: fotos, notas, etc. Pero no podemos usar SUID y necesitamos cambiar manualmente a ese usuario antes de iniciar la aplicación (con contraseña). El problema de esta opción son los procesos hijos. No podemos permitir que todos los procesos secundarios del programa de confianza sean confiables (si abrimos el archivo de medios en el administrador de archivos de confianza, no queremos que el reproductor de medios herede el estado de confianza del administrador de archivos). Pero tampoco podemos permitir que todos los procesos secundarios omitan sus permisos en forma predeterminada. ¡También malo!
  4. Usamos SELinux para implementar dominios "confiables" para cada aplicación confiable. No podemos usar la transición automática de dominio en este caso. Así que tenemos que cambiar de dominio con contraseña. Esta opción es ligeramente mejor que la # 3 porque podemos prohibir el lanzamiento de aplicaciones que no sean de confianza en dominios tan confiables. Pero sigue siendo malo e incómodo.
  5. Si pensamos más, estamos empezando a ver que no podemos vincular los permisos a los binarios ejecutables en absoluto. Por ejemplo, el intérprete de Python puede necesitar diferentes permisos dependiendo del script que ejecuta. Así que podemos olvidarnos de las opciones # 1 y # 2.
  6. Podemos hacer nuestro propio módulo LSM (como SELinux). Pero, ¿cómo se supone que funciona? No estoy seguro de que tenga ideas. ¿Modo interactivo? ¿Pedir permiso al usuario cada vez que algún proceso intenta leer archivos privados? ¿O deberíamos tomar algunas ideas del modelo "lomac" (marca de agua baja)? Por ejemplo, leer datos que no son de confianza hace que el entorno esté contaminado y lo bloquea al no leer datos privados.
  7. ¿Demonio del espacio de usuario + biblioteca LD_PRELOAD? En este caso, las aplicaciones no tienen acceso a archivos privados de forma predeterminada, pero pueden ponerse en contacto con daemon privilegiado y pedirle que abra dichos archivos y pase el descriptor de archivos. Esto es factible y se verá como "cortafuegos interactivos" para Windows.

¿Más ideas? Por favor, dime que sabes una solución ya hecha :)

ACTUALIZAR

Comencé a desarrollar mi propio LSM (reemplazo de SELinux). Parece que aquí nadie está interesado. Pero, por si acaso, puedes encontrarme aquí:

enlace

o aquí:

[email protected]

    
pregunta Sion0 16.09.2018 - 09:43
fuente

3 respuestas

1

No encontré ninguna solución que me convenga. Entonces, al final, comencé a desarrollar mi propio LSM (Módulo de seguridad de Linux). Actualmente, se encuentra en la etapa inicial de desarrollo, pero ya permite lograr (casi) lo que quería. Aquí están los principios básicos:

  1. El usuario puede definir hasta 64 permisos. Los permisos se identifican por número, pero también pueden tener alias legibles. Ejemplos:

    • 1="Permiso para leer fotos privadas"
    • 2="Permiso para leer y escribir cookies del navegador"
    • 3="Permiso para leer y escribir notas privadas"

  2. Usando una utilidad simple, el usuario puede marcar cualquier archivo para establecer:
    a) permisos requeridos para leer este archivo;
    b) permisos requeridos para modificar este archivo; c) permisos que puede tener este archivo si se ejecuta.
    Ejemplos:

    • Hacemos el permiso # 1 (lea las fotos privadas) para leer algún archivo de foto en particular.
    • Establecemos que el programa "/ bin / firefox" no puede tener ningún permiso si se ejecuta (sin sentido porque es predeterminado).
    • Establecemos que el programa "/ bin / cat" puede tener cualquier permiso si se ejecuta.
    • Establecemos que el programa "/ bin / imageview" puede tener el permiso # 1 pero no cualquier otro.

  3. IMPORTANTE Los programas (procesos) no pueden tener permisos que sus padres no tienen. Ejemplos:

    • "/ bin / firefox" no puede usar "/ bin / cat" para leer una foto privada. "cat" perderá todos los permisos si es lanzado por "firefox".

  4. PID 1 (padre de todos los procesos de espacio de usuario) comienza con permisos completos. Después de eso, los permisos de Todos los programas se determinan mediante la eliminación de los permisos que este programa no tiene de sus padres. permisos.

  5. De forma predeterminada, los programas no tienen permisos. Y los archivos no necesitan permisos para leerlos / modificarlos. Así que habilitar mi LSM no puede romper nada.

  6. También hay planes para implementar permisos del sistema como "usar internet" o "usar micrófono".

Algo como esto ... Por favor, dime si ves brechas críticas en esa lógica.

En mi PC, me vi obligado a otorgar permisos completos para los siguientes programas: systemd, agetty, iniciar sesión, bash, xinit, sh, startkde, start_kdeinit_wrapper, start_kdeinit, kdeinit5, konsole

Ahora los programas que lanzo desde el menú de KDE o desde konsole pueden tener permisos. Pero la mayoría de ellos no tengo alguno por supuesto.

    
respondido por el Sion0 24.09.2018 - 18:42
fuente
4
  

Las aplicaciones no deben tener acceso a los datos de otras aplicaciones ni a los datos privados del usuario, a menos que el usuario lo permita. ¿No es esto una necesidad obvia?

No, esto no es obvio. Tradicionalmente, el software instalado en el sistema se consideraba de confianza, es decir, no se esperaba que los usuarios solo fueran a Internet y descargaran alguna aplicación dañina posible. Tampoco se esperaba que los usuarios ejecutaran software inseguro que pudiera interactuar mal con algún sitio remoto y, por lo tanto, dar a un atacante remoto acceso a datos locales.

Por lo tanto, el límite de seguridad en UNIX (y otro sistema operativo) es por diseño del usuario y no de la aplicación. De hecho, ni siquiera hay un concepto de aplicación como le gustaría tener: las aplicaciones complejas (como Office) están compuestas de varios binarios, bibliotecas, archivos de configuración, etc.

Creo que este diseño sigue siendo válido en muchos casos de uso, es decir, casos en los que los sistemas no se modifican mucho en primer lugar o donde solo se instala software de confianza. Pero ahora también hay casos en que los usuarios realmente instalan software de fuentes potencialmente no confiables o instalan software potencialmente inseguro y esperan que este software no haga mucho daño. En estos casos, el paradigma original de usar solo al usuario como límite de seguridad no es suficiente.

Hay sistemas operativos diseñados con un paradigma diferente, es decir, donde es común que los usuarios descarguen posibles aplicaciones malintencionadas de Internet y deseen restringir el acceso a datos privados. Por ejemplo, en Android, cada aplicación se instala esencialmente como su propio usuario y, por lo tanto, el límite del usuario se utiliza para restringir el acceso a los datos generados por otra aplicación (esto se simplifica un poco sobre cómo funciona).

Por lo tanto, si considera que las aplicaciones no son de confianza por defecto, es mejor que ejecute un sistema operativo que esté diseñado alrededor de este paradigma desde el principio en lugar de intentar modificar un sistema operativo que haya sido diseñado con un paradigma diferente. Como usted mismo se dio cuenta, cualquier intento de aplicar los conceptos de aplicaciones no confiables a un sistema diseñado alrededor de aplicaciones confiables es torpe e incómodo de usar.

    
respondido por el Steffen Ullrich 16.09.2018 - 11:12
fuente
3

Recomiendo mirar AppArmor como una alternativa a SELinux; proporciona el comportamiento que desea y es más fácil de mantener. Sin embargo, es una gran cantidad de trabajo definir los perfiles de AppArmor adecuados para todos que quiera ejecutar, por lo que en general, solo lo usaría con programas poco confiables o de baja seguridad, a menos que el desarrollador / editor ha proporcionado un perfil.

Dicho esto ... los sistemas operativos de propósito general no están, en general, diseñados para este tipo de caja de arena. El sandboxing se ha vuelto cada vez más popular como una característica del sistema operativo en los últimos años, pero todavía hay buenas razones por las que no se implementa tan universalmente como se podría esperar. En resumen, el sandboxing es difícil de conseguir (tanto para los ejecutores de sandbox como para los desarrolladores que tienen que hacer que su aplicación funcione correctamente dentro de sandbox), y no es la forma en que la seguridad del sistema operativo de propósito general generalmente funciona y, por lo tanto, es incompatible con un montón de código heredado.

Los

enfoques tempranos para el sandboxing en Linux y sistemas operativos similares usaban a menudo chroot jails , y aún son una opción ( aunque son difíciles de hacer bien). Sin embargo, ahora hay otras opciones más configurables y menos frágiles. La "contenedorización" de procesos que utilizan sistemas como Docker hace que sea relativamente fácil separar los procesos del resto del sistema , aunque Docker en sí no está especialmente diseñado para el caso de uso que describe. Podría ser posible adaptarlo, o su tecnología, para sus usos.

En cuanto a otros sistemas operativos ...

  • FreeBSD admite "jails" (con un comando jail ) que Sandbox procesa. Probablemente es el más similar a usar Linux con técnicas de sandboxing, y de hecho ejecutará la mayoría del software de Linux y es compatible con gran parte del mismo hardware.
  • Las aplicaciones de Android se ejecutan en un espacio aislado, con los permisos especificados en un manifiesto que forma parte del paquete de la aplicación. Las versiones modernas de Android generalmente permiten un control preciso sobre los permisos que obtiene cada aplicación, por lo que no tiene que decidir entre otorgar a una aplicación todos los permisos que quiere y no ejecutar en absoluto. Aunque generalmente no está diseñado para ser utilizado como un sistema operativo de escritorio, tiene una amplia gama de software disponible y se puede convencer para que se ejecute en la mayoría de los equipos.
  • Chrom [e | ium] OS ejecuta aplicaciones en un espacio aislado, y es esencialmente un navegador web como sistema operativo. Es de uso limitado si no realiza la mayor parte de su trabajo en línea, aunque las versiones más recientes también pueden ejecutar aplicaciones de Android.
  • MacOS admite sandboxing y lo usa ampliamente para aplicaciones instaladas desde la tienda de aplicaciones. Sin embargo, las aplicaciones tradicionales de MacOS todavía se ejecutarán con privilegios completos. El software propietario (con algunos componentes de código abierto) y (legalmente) requiere el hardware de Apple.
  • Apple iOS ejecuta todas las aplicaciones en un espacio aislado con un modo de permisos similar a Android, pero es muy restrictivo en lo que permite. Muchas aplicaciones, pero muy restrictivas en el hardware en el que se ejecutará (iPad, iPhone, iPod Touch) y muy patentadas. También le da al propietario nominal un control mínimo de bajo nivel sobre el dispositivo.
  • Windows 10 admite el sandboxing de aplicaciones (utilizado para las aplicaciones de la tienda de aplicaciones y algunas aplicaciones integradas), aunque la mayoría de las aplicaciones tradicionales de Windows todavía se ejecutan con plena confianza (es difícil clasificar los programas de terceros). Software propietario, pero es compatible con la ejecución de binarios de Linux a partir de las versiones recientes (generalmente sin ningún sandboxing especial, y no es compatible con los módulos del kernel de Linux).
respondido por el CBHacking 16.09.2018 - 12:22
fuente

Lea otras preguntas en las etiquetas

¿Cuál es la relación entre los títulos de investigación de GPZ y Meltdown and Specter? ¿Los errores de la CPU Spectre y Meltdown afectan a AMD además de a Intel?