Reglas de control de acceso obligatorias, ¿cómo tratar con Python, Bash y otros intérpretes?

Question

Reglas de control de acceso obligatorias, ¿cómo tratar con Python, Bash y otros intérpretes?

#1 de Polynomial (1 votos)
#2 de catpnosis (0 votos)

1

Pregunta

(a) ¿Hay? y si es así, (b) ¿cuál es una forma estándar o aceptada para que los sistemas MAC traten con software complejo y en particular con Python, Bash y otros intérpretes? (en términos de creación de reglas para este tipo de software "complejo" y "versátil")

Por ejemplo, con python, me parece que no es práctico regular el acceso que recibe el proceso de python sobre la base de los ejecutables (que siempre serán los ejecutables de python, etc.). En el mejor de los casos, se regularía de acuerdo con la confiabilidad del código "python-script" involucrado (ya que esto también define los recursos necesarios).

Fondo

Con referencia a MAC (control de acceso obligatorio) aquí se pretende hacer referencia a cierto software como SELinux, grsecurity, TOMOYO, Apparmor y similares. (Todavía estoy luchando con el término correcto para referirme a esos conceptos y software, por eso lo expreso aquí, tratando de evitar la ambigüedad).
El MAC se concibe aquí como una herramienta / forma de mejorar la seguridad que va más allá de lo posible con el control de acceso discrecional (DAC).
Este "valor de seguridad adicional" se debe al control del acceso de una manera más detallada de lo que podría ser posible con el DAC. Como ejemplo, el acceso que recibe un software puede estar basado en algo más que solo el USUARIO con el que se inicia el proceso. Y, por supuesto, los archivos y recursos que pueden ser tocados por un determinado proceso están, en el mejor de los casos, ajustados al límite que el programa realmente necesita.
Se puede ver como un objetivo clave de un MAC para limitar el acceso al mínimo necesario.
Si limitar (por motivos de seguridad) el acceso de un programa a aquellos recursos que realmente solo necesita es algo que se desea de un sistema MAC, lo que parece más fácil / práctico para un software que tiene un alcance muy limitado. funcionalidad Del mismo modo, un software más versátil y complejo parece ser mucho más difícil de confinar y limitar.

mandatory-access-control

pregunta humanityANDpeace 19.12.2012 - 09:51

fuente

2 respuestas

Lea otras preguntas en las etiquetas mandatory-access-control

almacenamiento en la nube cifrado con copia local parcial ¿Está Business Endpoint Security de Webroot a la altura de la fuerza laboral móvil?

score 1 · Answer 1

Para los idiomas completos de Turing, no puedes detectar lo que van a hacer o acceder antes de tiempo. Puede intentar detectar ciertas cosas en función del uso de varias palabras clave y clases de marcos específicos del idioma, pero no es fácil.

Supongamos que intenta impedir que alguien llame a alert() en Javascript. Considera lo siguiente:

exec(
  atob('dmFyIHQ9MSx4PTA7eD1NYXRoLmxvZyh0KTsgaWYoeDwxKXthbD9ydCgnZGVycCcpO30=')
    .replace(/\?/g,'t')
);

¿Realmente puedes escribir algo que siempre identifique las llamadas de alerta? ¡No!

La única forma de lograr esto es proporcionar el control a un nivel bajo, por ejemplo. dentro de alert() en sí. Obviamente esto no es ideal; ¿Puedes conectar todos los motores de JavaScript posibles en cada navegador? De nuevo, no. Por lo tanto, tiene que bajar aún más, tal vez conecte todas las llamadas a la API del sistema utilizada para crear nuevas ventanas. Oh, pero ahora necesitas poder distinguir la diferencia entre un mensaje alert() y una ventana normal.

No es tan fácil como podría parecer, ¿verdad?

Este es precisamente el motivo por el que la mayoría de los sistemas de control de acceso obligatorios se centran exclusivamente en el acceso a recursos , en lugar de a las operaciones. Debe saber de antemano contra qué está tratando de protegerse, y debe saber cómo se va a acceder a ese recurso. Como tal, no hay una forma genérica de hacer lo que quiere, incluso en un idioma específico. Debe configurar manualmente las restricciones con anticipación.

score 0 · Answer 2

Es necesario restringir no python en todo el script de Python, sino en particular. (Por ejemplo, /usr/bin/rdiff-backup ). AFAIK, Smack y TOMOYO (y CaitSith) apoyan este enfoque. Entonces, el script de amenazas lanzó directamente (por lo tanto, debería tener #!/usr/bin/python como primera línea y + x permisos) como poseedora de dominio (en TOMOYO) o propietaria de etiquetas de seguridad adjuntas al archivo de script (Smack).

Además, TOMOYO admite la transferencia de dominio manual, esto es útil para cosas como Apache (con mod_tomoyo). El script (si está permitido) puede cambiar "manualmente" a otro dominio de seguridad, al acceder, por ejemplo, a datos de un usuario en particular.