Una política de MAC debe ser extremadamente detallada , no necesariamente extremadamente restrictiva .
Puede disminuir la seguridad bajo ciertas condiciones. Las aplicaciones, especialmente las complejas, a menudo tienen fallbacks cuando no se puede acceder a un recurso dado. Las razones de esto pueden ser desde no poder acceder a un servicio de seguridad hasta ingresar a un modo de compatibilidad inseguro para un sistema más antiguo y menos seguro. A veces, el problema es simplemente que la aplicación no se ha probado a fondo y el hecho de no poder acceder a un recurso normalmente presente conduce a errores de seguridad.
Al desarrollar una política de control de acceso, es importante que ninguno de los intentos normales de acceso a los recursos para las aplicaciones incluidas en la lista blanca sea negado a menos que tenga una comprensión sólida de todas las implicaciones de negar el recurso. Por ejemplo, negar el acceso a /etc/localtime puede dar como resultado que una aplicación use solo la hora UTC, mientras que el bloqueo del acceso a un archivo estándar que se garantiza que existe en todos los sistemas puede causar errores graves e imprevistos. Cuando se activa un acceso denegado, el evento se debe registrar para una revisión posterior. Si descubre que el acceso es benigno y no es probable que aumente la superficie de ataque, puede agregarlo a la lista blanca.
Le sugiero que consulte las abstracciones de AppArmor que permiten la inclusión de políticas secundarias con fines específicos, como el acceso de audio a la lista blanca. Esto le permite simplificar su política agregando #include <abstractions/audio> en lugar de tener que incluir en la lista blanca objetos individuales. Esto hace que las políticas de AppArmor sean mucho más simples de lo que serían de otra manera, al tiempo que mantienen un alto nivel de seguridad. Muchas arquitecturas de MAC admiten una función similar.