Defensa en profundidad con controles de seguridad comunes

4

Muchos sistemas operativos implementan las capacidades del sistema, los controles de acceso Posix (DAC / ACL) y los controles de acceso obligatorios (SELinux), cada uno de los cuales utiliza diferentes controles de seguridad subyacentes para proporcionar capas individuales de seguridad, implementando así el principio de defensa en profundidad.

¿Qué pasaría si las capacidades del sistema, DAC y MAC se implementaran utilizando un mecanismo de seguridad subyacente común, se lograría una defensa en profundidad aun cuando los tres controles de seguridad tengan al menos una superficie de ataque común?

    
pregunta Whome 29.04.2016 - 15:17
fuente

3 respuestas

2
  

¿se lograría la defensa en profundidad a pesar de que los tres controles de seguridad tienen al menos una superficie de ataque común?

No, puede verlo muy bien con el software antivirus, por ejemplo: parece una defensa en profundidad al poner los sistemas de protección en varias capas (firewall de red, complemento de navegador, monitoreo de procesos, análisis de archivos, etc.), Sin embargo, un atacante solo tiene que derrotar una sola cosa, el software antivirus en sí, para hacer que todo el sistema de protección colapse.

Como se observa correctamente, el kernel de Linux no implementa sus verificaciones de autorización de manera monolítica, en su lugar, utiliza una forma modular en donde los módulos de seguridad (llamados LSM, consulte here y allí para más información pueden provenir de diferentes proveedores y completarse entre sí (por lo tanto, el sistema DAC del kernel se puede completar con capacidades y un sistema MAC que viene como módulos).

Esto ofrece varias ventajas, tanto en términos de libertad, que es el núcleo de la filosofía y seguridad de GNU / Linux:

  • Más libertad porque un módulo de seguridad no está estrechamente integrado al kernel, esto permite que un usuario (o más probablemente un mantenedor de distribución) seleccione el LSM que mejor se adapte a sus necesidades (lo que, al final, brinda más seguridad al final -usuario). Por ejemplo, algunos prefieren el modelo de seguridad de AppArmor, otros prefieren el modelo de SELinux, etc.: la elección no es impuesta por el equipo de desarrollo del kernel de Linux. Esto se establece explícitamente en la página de Wikipedia previamente vinculada :

      

    Linus Torvalds rechazó a SELinux en ese momento, porque observó que hay muchos proyectos de seguridad diferentes en desarrollo, y como todos difieren, la comunidad de seguridad aún no ha logrado un consenso sobre el modelo de seguridad definitivo. En su lugar, Linus cargó a la comunidad de seguridad para "convertirlo en un módulo".

  • Seguridad por dos razones, que ambas terminan siendo beneficiosas del aislamiento del código:

    • Una corrección hecha en una característica de seguridad no debería causar ningún problema en otra. Una actualización en SELinux, por ejemplo, no debería afectar a los sistemas de autorización de DAC o capacidades, ya que cada uno utiliza un código y estructuras de datos distintos. Este no sería el caso si todo esto se implementara como una única pieza de software monolítica.

    • Una vulnerabilidad que afecta a una característica de seguridad no debe poner en peligro las otras. En caso de que la vulnerabilidad afecte a SELinux, por ejemplo, dicha vulnerabilidad no anulará los sistemas de seguridad de DAC y capacidades como en el ejemplo de antivirus que se muestra arriba, donde una vulnerabilidad en el software antivirus probablemente cancelará todos sus beneficios de seguridad.

La defensa en profundidad no debe concebirse como simplemente con varias capas de controles de seguridad, en lugar de eso, debe considerarse simplemente como tener varias capas de sistemas de seguridad . De hecho, es el aislamiento entre cada sistema lo que le brindará una buena garantía de que un atacante tardará en vencer su infraestructura de seguridad.

    
respondido por el WhiteWinterWolf 28.08.2016 - 10:05
fuente
0

Sospecho que dac y mac son lo suficientemente distintos como para que si intentas minimizar el código utilizando una infraestructura común, la cantidad de código compartido sea pequeña. Personalmente los haría por separado, y luego revisaría y marcaría cualquier cosa que pareciera demasiado similar ...

    
respondido por el davecb 30.04.2016 - 01:35
fuente
0

Tienen una superficie de ataque común: el núcleo. DAC, MAC y las capacidades dependen del núcleo para su implementación. Por lo tanto, las fallas en el kernel que permiten la ejecución remota de código fallarán en todos estos mecanismos, obviamente. Esto también se aplica a los espacios de nombres de Linux.

Afortunadamente, estos mecanismos de seguridad reducen la exposición a las API del kernel para procesos no privilegiados y, por lo tanto, los riesgos asociados con las vulnerabilidades del kernel. La defensa en profundidad debe ser que los límites múltiples deben romperse / los sistemas deben comprometerse, uno tras otro, para que un adversario se beneficie de un atacante. En el caso de sistemas operativos y procesos no privilegiados, es mejor razonar sobre la medida en que cada capa protege las API, en lugar de en un formato binario.

Por ejemplo, si las políticas de su sandbox en el espacio de nombres y SELinux permiten el acceso directo a la memoria en las GPU, las vulnerabilidades relacionadas con los controladores de GPU pueden ser más fáciles de acceder para que todo el sistema caiga como si no lo hicieran. Entonces, en última instancia, hay un único punto de falla (el núcleo aquí), hay muchas maneras de interactuar con él (algunas peligrosas, otras no), hay vulnerabilidades, y es la política y la configuración lo que establecerá la facilidad de ataque en lugar de La mera presencia de mecanismos de seguridad.

    
respondido por el Steve DL 27.10.2016 - 11:37
fuente

Lea otras preguntas en las etiquetas