Ejecutables firmados bajo Linux

Me doy cuenta de que esta es una pregunta antigua, pero acabo de encontrarla.

Escribí soporte de ejecutables firmados para el kernel de Linux (alrededor de la versión 2.4.3) hace un tiempo, y tenía toda la cadena de herramientas en su lugar para firmar ejecutables, verificando las firmas en execve(2) tiempo, almacenando en caché la información de validación de la firma (borrando la validación cuando el archivo se abrió para escribir o modificar), incrustando las firmas en programas ELF arbitrarios, etc. Introdujo algunas penalizaciones de rendimiento en la primera ejecución de cada programa (porque el kernel tuvo que cargar en el todo archivo, en lugar de solo solicitar las páginas necesarias), pero una vez que el sistema estuvo en un estado estable, funcionó bien.

Pero decidimos dejar de seguirlo porque enfrentaba varios problemas que eran demasiado grandes para justificar la complejidad:

• Todavía no habíamos creado soporte para bibliotecas firmadas . Las bibliotecas firmadas también requerirían modificar el ld.so cargador y el dlopen(3) mecanismo. Esto no era imposible, pero complicó la interfaz:¿debemos hacer que el cargador le pida al kernel que valide una firma o el cálculo debe realizarse completamente en el espacio del usuario? ¿Cómo se protegería uno contra un strace(2) d proceso si esta parte de la validación se realiza en el espacio de usuario? ¿Nos veríamos obligados a prohibir strace(2) completamente en tal sistema?

  ¿Qué haríamos con los programas que suministran su propio cargador?

• Muchos programas están escritos en lenguajes que no se compilan en objetos ELF. Tendríamos que proporcionar específico del idioma modificaciones a bash , perl , python , java , awk , sed , y así sucesivamente, para que cada uno de los intérpretes pueda también validar firmas. Dado que la mayoría de estos programas son texto sin formato de formato libre, carecen de la estructura que facilitó la incorporación de firmas digitales en archivos de objetos ELF. ¿Dónde se almacenarían las firmas? ¿En los guiones? ¿En atributos extendidos? ¿En una base de datos externa de firmas?

• Muchos intérpretes están muy abiertos sobre lo que permiten; bash(1) puede comunicarse con sistemas remotos totalmente por sí mismo usando echo y /dev/tcp , y se puede engañar fácilmente para que ejecute cualquier cosa que un atacante necesite hacer. Firmados o no, no se podía confiar en ellos una vez que estaban bajo el control de un hacker.

• El motivador principal para la compatibilidad con ejecutables firmados proviene de los rootkits que reemplazan el /bin/ps proporcionado por el sistema. , /bin/ps , /bin/kill , y así. Sí, hay otras razones útiles para tener archivos ejecutables firmados. Sin embargo, los rootkits se volvieron significativamente más impresionantes con el tiempo, y muchos dependían de kernel. hacks para ocultar sus actividades a los administradores. Una vez que el kernel ha sido pirateado, todo el juego termina. Como resultado de la sofisticación de los rootkits, las herramientas que esperábamos evitar que se usaran estaban perdiendo el favor de la comunidad de hackers.

• La interfaz de carga de módulos del núcleo estaba abierta de par en par. Una vez que un proceso tiene root privilegio, fue fácil inyectar un módulo del kernel sin ninguna verificación. También podríamos haber escrito otro verificador para los módulos del kernel, pero la infraestructura del kernel en torno a los módulos era muy primitiva.

El modelo GNU/Linux/FOSS en realidad fomenta la manipulación, en cierto modo. Los usuarios y los creadores de distribuciones deben tener la libertad de modificar (manipular) el software para adaptarlo a sus necesidades. Incluso volver a compilar el software (sin cambiar ningún código fuente) para la personalización es algo que se hace con bastante frecuencia, pero rompería la firma de código binario. Como resultado, el modelo de firma de código binario no es particularmente adecuado para GNU/Linux/FOSS.

En cambio, este tipo de software se basa más en la generación de firmas y/o hash seguros de los paquetes fuente. En combinación con un modelo de distribución de paquetes confiable y confiable, esto puede ser tan seguro (si no más, en relación con la transparencia en el código fuente) como la firma de código binario.

El módulo del kernel DigSig implementa la verificación de archivos binarios firmados por una herramienta llamada bsign . Sin embargo, no ha habido ningún trabajo en él desde la versión 2.6.21 del kernel de Linux.

Eche un vistazo a esto:http://linux-ima.sourceforge.net/

Todavía no está firmando, pero aún permite la verificación.