¿Hay algún sistema operativo que verifique las firmas de los programas antes de ejecutarlos?

iOS y Android validan la firma de cada pieza de código antes de cargarlos en la memoria.

Las aplicaciones de Windows UWP también se comprueban para su firma antes de ser cargadas también.

  

La verificación de la firma del paquete es bastante común con los administradores de paquetes de hoy. Lo que pregunto es la verificación de la firma en el momento de la carga.

La diferencia es masiva en términos de actuaciones. Se comprueba una firma de paquete cuando se instala y no después.

Para que sea efectivo, la firma del código debe verificarse para cada binario antes de ejecutarse o cargarse.

Además, el sistema operativo (o el entorno de ejecución) debe tener especial cuidado para asegurarse de que una página de memoria marcada como ejecutable esté firmada (o, al menos, que se haya cargado de algo que esté correctamente firmado). Esos requisitos son extremadamente difíciles de hacer cumplir en cualquier entorno que no haya sido diseñado teniendo en cuenta la firma de código porque tiende a romper muchos códigos heredados.

¿Por qué no todos los sistemas operativos verifican la firma de los programas? Simplemente porque en los primeros tiempos, la mayoría de los programas se escribían y compilaban localmente, y aún hoy en día, algunas aplicaciones comerciales se crean específicamente a nivel local. Una gran cantidad de programas de alta calidad se distribuyen como fuente y puede ser compilado localmente. A menudo tiene sentido en servidores de alto rendimiento porque las opciones de compilación se pueden usar para modificar un programa para necesidades específicas. Si solo pudieras usar un ejecutable firmado de fuentes conocidas, todo eso no sería posible.

Por supuesto, para un sistema operativo dirigido a usuarios finales como Android o iOS, las cosas son diferentes, y tiene sentido permitir que solo se instalen ejecutables de fuentes bien conocidas.

Pero incluso en mi caja de Windows, me sentiría muy decepcionado si no pudiera escribir, compilar y ejecutar un programa en C o C ++ ...

Un ejemplo que se usa ocasionalmente en entornos educativos y corporativos es AppLocker , que puede restringir la ejecución de la aplicación a una lista blanca basada en atributos definidos por el administrador, incluido el nombre del editor de una firma o el hash de un archivo específico.

El mayor problema es, por supuesto, la sobrecarga de administración, que tiene que incluir específicamente en la lista blanca todos los programas que un usuario pueda necesitar. Además, muchos editores no firman sus aplicaciones. Y, por supuesto, no es una solución infalible, por ejemplo, un error en un programa incluido en la lista blanca aún podría ser explotado para ejecutar código arbitrario ¹ .

En realidad, la firma del ejecutable no es ni siquiera la parte importante. La lista blanca se puede implementar por ruta para toda la diferencia que haga. Lo importante en este esquema es que el usuario no tiene permisos de escritura en el directorio del programa ² . Suponiendo que eso sea cierto, ¿qué ventaja ofrece la verificación en el tiempo de ejecución sobre la verificación en el momento de la instalación? Nadie puede cambiar el programa instalado. Si el vector de ataque es la edición de archivos sin conexión, la encriptación completa del disco es la respuesta correcta.

¹ La mayoría de estos errores no se considerarían graves en un entorno normal, donde no conducirían a una escalada de privilegios. W ^ X todavía se puede omitir con ROP .

² Incluso la verificación de la firma del ejecutable faltará a los módulos externos (por ejemplo, bibliotecas con vínculos dinámicos) de forma predeterminada. Y habilitar que puede tener impactos significativos en el rendimiento .

Linux ya tiene los mecanismos necesarios en el kernel (desde la versión 3.7), llamados IMA :

  

Los objetivos del subsistema de integridad del kernel son detectar si los archivos se han alterado accidental o malintencionadamente, tanto de forma remota como local, evaluar la medición de un archivo contra un valor "bueno" almacenado como un atributo extendido y hacer cumplir la integridad del archivo local. Estos objetivos son complementarios a las protecciones de Control de acceso obligatorio (MAC) proporcionadas por los módulos de LSM, como SElinux y Smack, que, según la política, pueden intentar proteger la integridad del archivo.

Con IMA, los archivos confidenciales se pueden etiquetar como "inmutables" (que es lo que haría con los archivos ejecutables), que los firma con una clave RSA especial. La firma se valida en el acceso a archivos, lo que evita la manipulación fuera de línea. La ejecución de archivos que no son inmutables puede prohibirse a través de las políticas de SElinux.

Por supuesto, la facilidad de uso de dicho sistema se reduce. Para crear y ejecutar sus propios archivos en dicho sistema, necesitará una clave privada de confianza para firmarlos primero. Es probable que las actualizaciones de software requieran un reinicio para actualizar archivos inmutables antes de que se bloqueen.

La verificación del tiempo de carga es muy costosa y no es infalible.

  

¿Hay algún sistema operativo que verifique las firmas de los programas antes de ejecutarlos?

EDIT : como se señaló en los comentarios, tales sistemas operativos. ChromeOS para, por ejemplo,

  

Si es así, ¿cuáles son estos sistemas operativos? ¿Están especialmente diseñados? ¿Qué tan difícil es aplicar este tipo de verificación de programa a los sistemas operativos diarios que utilizamos?

Es bastante difícil verificar un programa en el momento de la carga. Además, incluso si lo hace con éxito, una vez que se ha iniciado un programa, el atacante todavía puede dar una entrada con formato incorrecto y causar estragos (desbordamientos de búfer). Dicho esto, hay módulos de software que verifican sus firmas en el momento de la carga (atestación de software, por ejemplo, compatible con FIPS OpenSSL). Tener un sistema operativo que lo haga para todos y cada uno de los procesos es muy costoso.

A medida que el enfoque se desplaza hacia la computación en la nube, querrá asegurarse de poder ejecutar software de alta seguridad incluso en sistemas que no sean de confianza. Diría que no se realizaría mucha investigación sobre la protección del sistema contra el software que se ejecuta en él. En cambio, el enfoque estará más en hacer computación confiable incluso en un entorno no confiable. Puede tener una cadena de confianza básica como sistema o certificado de software (consulte el enlace inferior) si lo desea en el momento de la carga. Lo importante sería garantizar que el software no se vea comprometido en el tiempo de ejecución.

Mire esta discusión: ¿Puede un programa interpretado en ejecución probar criptográficamente que es lo mismo que una versión de código fuente publicada?

Muchas respuestas mencionan sistemas operativos generales que tienen un soporte relativamente reciente, pero no veo ninguna mención de TPM y del Trusted Computing Group . Un TPM proporciona el hardware mínimo necesario para realizar la ejecución firmada con una cadena de integridad desde el inicio del firmware como un módulo de placa base de grado de consumidor estandarizado. Funciona al permitir que las etapas de inicio extiendan los registros hash con las mediciones de cada etapa posterior antes de la ejecución, y luego proporciona un mecanismo de almacenamiento de claves bloqueado que puede ser condicional a estos valores de registro hash.

Con el TPM resolviendo el problema de Chicken and Egg para la PKI y el inicio temprano, el acceso a los recursos se podría restringir al software permitido en una política específica en la medida en que el código fuera libre de explotación. Sin un inicio verificado, hay poco sentido en la comprobación de firmas en tiempo de ejecución sin ninguna razón para creer que el sistema y la política de PKI no están modificados.

Según mi conocimiento (que no es actual), solo Apple y Google tenían el control suficiente de sus plataformas de hardware para experimentar con TPM predeterminados y no creo que ninguno de los dos implementara un estilo TCG completo de arranque verificado. Pero la amenaza de quedarse atrás por una repentina captación de estos nuevos dispositivos hizo que los proveedores de sistemas operativos comenzaran a implementar algunos componentes de integridad en tiempo de ejecución.

NetBSD tiene veriexec.

enlace

enlace

Es muy adecuado para servidores orientados a Internet, junto con un nivel de seguridad elevado ( enlace ).

En primer lugar, claramente no soy un experto en nada de lo que voy a decir, así que ten cuidado ...

En el mundo del software libre en el que vivo, la gente está trabajando en compilaciones reproducibles . El objetivo es que cada binario descargado pueda ser verificado por el propio usuario, bueno, construyéndolo. Muchos distribuciones y proyectos de software están interesados en ello. Si recuerdo correctamente, esta idea fue iniciada por la gente de bitcoin y seguida por el proyecto tor.

Por lo que he escuchado, algunas personas sugirieron que después de que muchos paquetes son reproducibles, el hash podría compartirse de alguna forma p2p. Entonces, para responder a su pregunta, en mi opinión, en el momento de la carga, un verificador simplemente puede hacer un hash del binario y verificar si coincide con el hash publicado por los demás, aunque esto puede ser lento dependiendo de la velocidad de su conexión a Internet (tal vez la conexión tenga que pasar por tor).

Además, conozco 2 distros más que otras, así que elaboraré más con ellas:
Por lo que he escuchado, Debian hará de reproducible-build un requisito de política luego de que muchos paquetes sean reproducibles.
Guix implementa el comando guix challenge para que uno pueda verificar el hash de su construcción local con la construcción oficial en Hydra.

No soy un "experto" sino solo un usuario común de algunas de las herramientas.

Estoy compartiendo sobre compilaciones reproducibles un poco más y como comentarios no fue el lugar correcto, por lo tanto, compartimos aquí. Por lo poco que comprendo, usado y experimentado, lo que hace es darle un paquete .deb junto con un archivo de texto .buildinfo. El archivo de texto buildinfo tendrá nombres y números de versión de todas las bibliotecas que se necesitaron en el entorno de compilación para crear el binario.

Entonces, si sospechas acerca de un paquete binario (desde el archivo o incluso desde afuera) que tiene el archivo de texto buildinfo, puede ser o no trivial probar los paquetes recreando el entorno de compilación exacto y comparando los hashes de los paquetes binarios finales.

También puede ser posible tener algún tipo de red de confianza para que más personas puedan saltar y decir que los hashes coinciden, lo que hace que sea un poco más confiable quizás . Puede haber casos de borde que no conozco.

Microsoft Windows 7+ se puede configurar para permitir solo Authenticode firmó programas para ejecutar.

Pero debes comprender que esto solo significa que sabes quién creó el virus que destruyó tu computadora. No es realmente una función de seguridad, porque no le dice nada acerca de una aplicación que está firmada. Sí, sabes que $ RANDOM_GUY de China, Ucrania, Angola, donde sea que lo haya creado. Pero ¿de qué le sirve esto realmente, si sus datos valiosos están encriptados y $ RANDOM_GUY exige 20BTC para descifrarlos? Y si el software le roba todos sus datos, ¿de qué le servirá que sepa que RANDOM_GUY probablemente lo robó?