En esta entrada quiero refrescar la memoria a todos nuestros lectores acerca de las políticas de acceso más comunes en el área de la informática: Mandatory Acces Control (MAC) y Discretionary Acces Control (DAC). Asimismo, y si el tiempo me lo permite, me gustaría aprovechar para iniciar una serie de entradas acerca de SELinux.

Pero vayamos a la cuestión: ¿qué es el MAC, DAC y cuales son sus diferencias?

Discretionary Acces Control es una forma de acceso a recursos basada en los propietarios y grupos a los que pertenece un objeto. Se dice que es discrecional en el sentido de que un sujeto puede transmitir sus permisos a otro sujeto. La mayoría de sistemas Linux ahora mismo usan este tipo de acceso, estando los permisos orquestados por grupos y usuarios, pudiendo un usuario normal cambiar los permisos de los archivos que posee con el comando chmod.

Mandatory Acces Control en cambio se basa en políticas. Existen un conjunto de reglas de autorización (políticas) las cuales determinan si una operación sobre un objeto realizada por un sujeto esta o no permitida basándose en los atributos de ambos. En este caso, el Mandatory refleja el hecho de que las políticas están centralizadas y no pueden ser sobrescritas por un sujeto.

Hace poco tuvimos la necesidad de incluir unos certificados SSL firmados por VeriSign para la navegación HTTPS en un proxy inverso Squid. El problema fue el hecho de que el cliente que lo requería había gestionado personalmente la creación y firma del certificado con una entidad certificadora internacional, la cual realizó todo el proceso con una herramienta propietaria basada en JAVA. Esto hizo que nosotros recibiéramos un fichero binario ilegible por OpenSSL, y sobre todo, por Squid.

Tras indagar un poco y averiguar que la aplicación del cliente había hecho uso de la herramienta keytool de JAVA respiré aliviado, pues suponía que seria trivial obtener los datos. Primeramente, pensando que en 20 minutos podría estar almorzando inspeccione el contenedor mediante el comando:

# keytool -list -v -keystore server_keystore

En mis primeros días de Erasmus en Londres, un profesor de una asignatura sobre sistemas distribuidos y seguridad nos dio a leer un curioso texto llamada “Worse is better” (Peor es mejor) donde se explicaba, a través de una curiosa discusión sobre sistemas operativos entre una persona del MIT y otra de la universidad de Berkeley, dos escuelas totalmente diferentes a la hora de llevar a termino un proyecto.

Mientras la escuela nacida del MIT defendía hacer las cosas “correctamente”, tomara el tiempo y el esfuerzo que tomara, y siguiendo los principios básicos de simplicidad, corrección, consistencia y completitud, la postura de la gente de Berkeley era más pragmática y hacia más hincapié en obtener un producto “suficientemente bueno” en un tiempo razonable, de forma que pudiera ser usado lo más pronto posible y a partir de ahí ir corrigiendo los fallos que pudieran quedar.

Estas dos filosofías se pueden aplicar a prácticamente cualquier ámbito de la informática, incluyendo, por supuesto, la seguridad. Ante el lanzamiento de un producto o servicio totalmente nuevo para la compañía, se puede optar por hacer análisis exhaustivos, empaparse de toda la documentación disponible perfilando al milímetro cada aspecto del proyecto y realizando complejas pruebas para asegurar que no existe ningún fallo de seguridad —llegando incluso a descartar el proyecto por no poder conseguir un producto realmente seguro tomando el tiempo que ello requiera— o por el contrario se puede hacer un análisis más ligero, ajustar los aspectos críticos e imprescindibles que realmente puedan poner en verdadero peligro al proyecto, y lanzar una versión suficientemente buena como para que los usuarios la adopten en un plazo aceptable, mientras sobre la marcha se van puliendo todos los aspectos que se quedaron en el tintero.