Ejecutables firmados bajo Linux

Question

Por razones de seguridad, es conveniente comprobar la integridad de código antes de la ejecución, evitar alterado software por un atacante.Entonces, mi pregunta es

Cómo firmar el código ejecutable y sólo se ejecutan software de confianza bajo Linux?

He leído la obra de van Doom et al., Diseño e implementación de firmado ejecutables para Linux, y el de IBM TLC (De confianza de Cliente de Linux) por Safford & Zohar.TLC usa TPM controlador, lo que es agradable, pero el papel es de 2005 y yo era incapaz de encontrar alternativas actuales.

¿Sabes otra de las opciones?

ACTUALIZACIÓN:Y acerca de otros sistemas operativos?OpenSolaris?BSD familia?

Answer 1

El DigSig kernel módulo implementa la verificación de los 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.

Answer 2

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

Escribí ejecutable firmado con soporte para el kernel de Linux (en torno a la versión 2.4.3) hace un tiempo, y todo el conjunto de herramientas en el lugar para la firma de los ejecutables, la comprobación de las firmas en execve(2) tiempo de almacenamiento en caché de la firma de validación de la información (borrado de la validación cuando el archivo se abre para escribir o modificar de otra manera), la incorporación de las firmas en arbitraria ELF programas, etc.Lo hizo introducir algunas penalizaciones de rendimiento en la primera ejecución de cada programa (debido a que el núcleo tenía que cargar en el todo archivo, en vez de sólo la demanda de la página de la necesaria páginas), pero una vez que el sistema se encontraba en un estado estacionario, que funcionaba bien.

Pero hemos decidido dejar de perseguir ya que se enfrenta a varios problemas que eran demasiado grandes para justificar la complejidad:

• Aún no se había construido el soporte para firmado bibliotecas.Firmado bibliotecas requeriría la modificación de la ld.so cargador y el dlopen(3) el mecanismo.Esto no era imposible, sino que lo hizo a complicar la interfaz:debemos tener el cargador de pedir el kernel para validar una firma o si el cálculo se realiza completamente en el espacio de usuario?¿Cómo se podía proteger contra un strace(2)d proceso si esta parte de la validación se realiza en el espacio de usuario?Estaríamos obligados a prohibir strace(2) completamente de tal sistema?

  ¿Qué podemos hacer al respecto los programas que suministran su propio cargador?

• Un gran número de programas se escriben en lenguajes que no compilar objetos ELF.Tenemos que proporcionar específico del lenguaje modificaciones a bash, perl, python, java, awk, sed, y así sucesivamente, para cada uno de los intérpretes de ser capaz de también validar las firmas.Dado que la mayoría de estos programas son gratis, en formato de texto sin formato que carecen de la estructura de la incrustación de firmas digitales en ELF objeto de archivos es tan fácil.Qué sería de las firmas ser almacenados?En las secuencias de comandos?En los atributos extendidos?En una base de datos externa de las firmas?

• Muchos intérpretes abiertos sobre lo permiten; bash(1) puede comunicarse con sistemas remotos completamente de su propia el uso de echo y /dev/tcp, y puede fácilmente ser engañados en la ejecución de cualquier cosa que un atacante necesita hacer.Firmado o no, no se podía confiar en ellos una vez que estaban bajo el control de un hacker.

• El principal motivador para que los ejecutables firmados apoyo proviene de los rootkits sustitución de la proporcionada por el sistema /bin/ps, /bin/ps, /bin/kill, y así sucesivamente.Sí, hay otras razones para tener ejecutables firmados.Sin embargo, rootkits tiene muchos más impresionante a lo largo del tiempo, con muchos confiar en kernel hacks para ocultar sus actividades de los administradores.Una vez que el kernel ha sido hackeado, el juego es terminado.Como resultado de la sofisticación de los rootkits de las herramientas que se fueron con la esperanza de impedir que sean utilizados fueron perdiendo popularidad en la comunidad ataque.

• El núcleo de la carga del módulo de interfaz fue abierto.Una vez que el proceso ha root privilegio, era fácil la inserción de un módulo de kernel sin ningún tipo de comprobación.Podríamos haber escrito también otro verificador de módulos de kernel, pero el núcleo de la infraestructura de alrededor de los módulos era muy primitivo.

Answer 3

El modelo de GNU / Linux / FOSS en realidad fomenta la manipulación - de una especie. Los usuarios y distribuciones de decisiones deben estar libres de modificar (manipular) el software para satisfacer sus necesidades. Incluso acaba de volver a compilar el software (sin cambiar el código fuente) para la personalización es algo que se hace muy a menudo, pero rompería binaria de firma de código. Como resultado, el modelo de firma de código binario no se adapta particularmente bien a GNU / Linux / FOSS.

En lugar de ello, este tipo de software se basa más en la generación de firmas y / o hash seguras de los paquetes fuente. En combinación con un modelo de distribución de paquetes fiable y de confianza, esto se puede hacer igual de seguro (si no más, la transparencia vis-à-vis en el código fuente) como binarios de firma de código.

Answer 4

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

No es la firma todavía, pero todavía permite la verificación.

Answer 5

Puedo responder a la cuestión desde una perspectiva de Solaris 10 y 11 OS, se firman todos los binarios. Para verificar el uso de la firma 'elfsign' ...

$ elfsign verify -v /usr/bin/bash
elfsign: verification of /usr/bin/bash passed.
format: rsa_sha1.
signer: O=Oracle Corporation, OU=Corporate Object Signing, OU=Solaris Signed Execution, CN=Solaris 11.
signed on: Fri Oct 04 17:06:13 2013.

Oracle han añadido recientemente un proceso de arranque verificado para Solaris 11 también, para más detalles véase - Solaris inicio verificado Introducción

Hay algunas horquillas grado de producción del código de OpenSolaris, tres vale la pena investigar son Illumos, SmartOS y OmniOS.

Answer 6

Tome un vistazo a Medusa DS9 . He jugado con él un largo ( los ) Hace tiempo, pero si no recuerdo mal, usted podría registrar binarios específicos y cualquier modificación no estaba permitido en el nivel del núcleo. Por supuesto, se puede anular con acceso local a la máquina, pero no fue muy fácil. Hay un demonio inteligente, llamada agente, comprobando todo lo que sucede en la máquina y si ocurre algo fuera de lo común, que empiezan a gritar.

Answer 7

Nunca he intentado pero echar un vistazo a: http: / /blog.codenoise.com/signelf-digitally-signing-elf-binaries . La solución funciona sin necesidad de soporte en el núcleo, y parece estar listo para funcionar.

El código para el firmante se puede encontrar en http://sourceforge.net/projects/signelf/

No resuelve el "código única carrera de confianza en Linux" pregunta, pero no soluciona parcialmente el problema haciendo una manera para que el programa para detectar una posible manipulación en sí / corrupción

Answer 8

http://en.wikipedia.org/wiki/PKCS

El uso de un PKCS7 (S/MIME) signo de ello.Generar su propio certificado/clave privada pareja, auto-firmar el certificado y, a continuación, firmar el archivo con la clave privada y el cert utilizando PKCS7.Va a adjuntar el certificado y, a continuación, se puede comprobar a sí mismo en tiempo de ejecución mediante el comando openssl (hombre smime, o simplemente no hacer openssl ayuda).Esto es a prueba de manipulaciones porque a pesar de que la clave pública se encuentra en los archivos de darle, el S/MIME, firma para la que la clave pública sólo puede ser generada con la clave privada de la cual no distribuir.Así que si el archivo está firmado por el cert, debe de haber sido firmado por alguien con la clave privada y, como no dar la clave privada a nadie, debe venir de usted.

Aquí es cómo hacer que el certificado auto-firmado.

http://www.akadia.com/services/ssh_test_certificate.html

Tendrás que convencer a openssl para confiar en su cert como una raíz de autoridad (CAfile), a continuación, comprobar con que como la raíz, y también comprobar el cert en el archivo es el suyo (el hash del certificado) y comprobar el hash.Tenga en cuenta que aunque no está documentado, el estado de salida de openssl refleja la validez de la señal de comprobación cuando se hace un smime verificar.Es 0 si coincide, no-cero si no.

Tenga en cuenta que todo esto no es seguro, porque si el cheque está en el código, simplemente puede quitar la marca de verificación si desea golpear a usted.La única forma segura de hacerlo sería tener el corrector en el sistema operativo y tener que comprobar su binario y se niegan a ejecutar si no está firmada.Pero ya que no hay corrector en el sistema operativo linux puede ser modificado para quitar/bypass de todos modos...Lo que esto es realmente bueno, es la detección de archivos corruptos más que tratar de mantener a la gente de omitir usted.

Answer 9

Estoy de acuerdo que la filosofía que rodea a Linux, GNU et al. gira en torno a pequeños ajustes. Por otra parte, también creo que algunos sistemas merecen una protección contra las vulnerabilidades tales como manipulación del software, que pueden socavar la privacidad e integridad de los usuarios de un sistema.

implementaciones de núcleo no puede mantenerse al día con el ciclo de desarrollo rápido del propio núcleo. Recomiendo en vez de implementar una forma de verificación de firma archivo ejecutable utilizando herramientas de usuario. Coloque los ejecutables en una imagen de archivo o sistema de ficheros y firmar la imagen utilizando una clave privada; si esa clave privada se mantiene en sus máquinas de desarrollo (privadas), cuando el servidor está pirateada, los atacantes todavía no tienen manera de firmar sus propias imágenes e inyectar su código sin engañar al sistema para montar imágenes sin firmar. Se extiende además a lo largo de la cadena:

• han sus servicios contenidos en tiempo de ejecución montado en imágenes de sólo lectura;
• haber la máquina funcionar con una firma, de sólo lectura del sistema de archivos;
• implementar arranque seguro en sus máquinas, la ejecución de un gestor de arranque que hace cumplir la integridad del medio de arranque;
• confianza que las personas de su organización no modificará sus máquinas.

El conseguir todo bien es una tarea difícil. Es mucho más simple de evitar todo por el diseño de su sistema bajo otro enfoque:

• cuarentena usuarios del sistema. No introducir medios para los usuarios ejecutar comandos en el sistema. Evitar los bombardeos a cabo desde el interior de los programas que se basan en los datos alimentados por el usuario.
• diseñar sus procedimientos de implementación mediante la administración de configuración y asegurarse de que sus despliegues son "repetible", lo que significa que conducen al mismo resultado funcional cuando se implementa varias veces. Esto le permite "arma nuclear desde la órbita" máquinas que sospeche que han sido comprometidos.
• tratar sus máquinas como si estuvieran comprometidos: ejecutar periódicamente auditorías para verificar la integridad de sus sistemas. Guarde los datos en imágenes separadas y volver a implementar sistemas con regularidad. Date de imágenes y tienen sistemas rechazan imágenes sin firmar.
• certificados de uso: favorecer un enfoque "certificado de colocación de clavos". No desplegar un certificado raíz para sus aplicaciones (que proporcionará el rechazo automático de las firmas que no han sido certificados por su organización), pero al menos tener el sistema de gestión de huellas digitales de imágenes actuales y notificar a los administradores cuando las huellas digitales han cambiado. Aunque es posible llevar a cabo todo esto utilizando cadenas de claves, la autenticación basada en certificados ha sido diseñado para esta aplicación exacta.

Answer 10

Me gusta pensar a la seguridad como una cadena. El enlace más débil de la cadena puede poner en peligro todo el sistema. Así que todo el asunto se convierta en " prevención de un usuario no autorizado de la obtención de la contraseña de root ".

Según lo sugerido por @DanMoulding la fuente del software también es importante y en el futuro, probablemente, las tiendas oficiales de aplicación OS será la norma. Piense en Play Store, las tiendas de Apple o Microsoft.

  

Creo que la instalación y distribución de código malicioso encubierta es la   problema mucho más insidioso. Después de todo, con el fin de cargar el código malo que es   Tiene que ser instalado por primera vez en el sistema en alguna parte. Más capas de   la seguridad son por lo general mejor, por supuesto. La pregunta es: ¿merece la pena   el costo?

En mi opinión la respuesta es "depende". Puede reducir el riesgo mediante la adopción de un conjunto de políticas de seguridad según lo sugerido por @sleblanc. Puede cifrar el sistema de archivos ( https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup ), utilizar los sistemas de archivos de sólo lectura para los binarios o utilizar un mecanismo para firmar y verificar los binarios.

Sin embargo cualquier mecanismo que se utiliza no hay nada que puede hacer una vez que el acceso a la raíz se obtiene por un atacante. Las herramientas de verificación de firma pueden ser sustituidos por una versión manipulada o simplemente personas con discapacidad y que en realidad no importa si las herramientas se ejecutan en espacio de usuario o espacio de núcleo, una vez que la máquina ha sido comprometida (aunque esto último sería más seguro, por supuesto, ).

Por lo tanto, sería bueno que el núcleo de Linux podría incorpora un módulo de verificación de firmas y otra capa de seguridad entre el usuario root y el sistema operativo.

Por ejemplo, este es el enfoque adoptado en la reciente macOS versiones. Algunos archivos no se puede modificar (y, a veces leer), incluso por la cuenta root y hay restricciones también sobre las políticas y los módulos del núcleo (por ejemplo, sólo se firmó o kext autorizado puede ser cargado en el sistema). Windows adopta más o menos el mismo enfoque con AppLocker .