Protección del espacio de direcciones, a través de la herramienta PAX se previene el abuso de los desbordamientos de buffer, además de proveer aleatoriedad a la administración de procesos en memoria.
Protección del sistema de archivos, sobre este aspecto existen restricciones en el /proc, que hacen que un usuario pueda ver únicamente sus procesos, además protecciones de ejecución en /tmp.
Registro de actividad en el “kernel”, configuración de varias opciones de auditoria.
Protección de ejecutables con la configuración de opciones que intervienen en la creación de procesos y a que binarios del sistema se puede acceder.
Protecciones de red con restricciones sobre que tipos de “sockets” podrán utilizar los usuarios y opciones de configuración relacionadas con la selección aleatoria de la pila TCP/IP.
Opciones de registros de eventos que permiten especificar el tiempo entre mensajes de notificación y el número máximo de estos mensajes.
Opciones de control de acceso basado en roles RBAC.
INSTALACION
El proceso de instalación se realizó sobre una versión de Linux con las siguientes características:
Distribución Ubuntu 8.04 Desktop i386
Kernel 2.6.24
En general, el proceso consiste en obtener los fuentes del kernel, obtener los parches de “grsecurity”, aplicar los parches al Kernel, recompilarlo e instalarlo.
Para compilar el kernel se necesitan instalar los siguientes paquetes:
apt-get install build-essential bin86 kernel-package
apt-get install libqt3-headers libqt3-mt-dev
Cambiamos de directorio
cd /usr/src
Bajamos los fuentes del kernel y los fuentes de “grsecurity“
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.tar.bz2
wget http://www.grsecurity.net/grsecurity-2.1.11-2.6.24.5-200804211829.patch.gz
Para el kernel 2.6.24 es necesario bajar la versión mas reciente de “grsecurity” que señala claramente en su nombre de archivo la versión del “kernel” a parchar.
Se descomprimen los archivos
tar –xjvf linux-2.6.24.tar.bz2
gunzip grsecurity-2.1.11-2.6.24.5-200804211829.patch.gz
Cambiamos de nombre al directorio donde se descomprimieron los fuentes y hacemos una liga con un nombre mas corto
mv linux-2.6.24 linux-2.6.24-grsec
ln -s linux-2.6.24-grsec linux
Cambiamos al directorio de los fuentes y copiamos a este directorio, el parche descompactado de “grsecurity”.
cd linux
cp /usr/src/grsecurity-2.1.11-2.6.24.5-200804211829.patch .
Aplicamos el parche
cat grsecurity-2.1.11-2.6.24.5-200804211829.patch "aqui va un pipe" patch –Np1
Con lo anterior ya tenemos listos los fuentes para configurar y compilar
Copiamos el archivo de configuración inicial que tenemos actualmente
cp /boot/config-2.6.24-19-generic .config
Configuramos lo que será el nuevo kernel
make xconfig
Aparece la siguiente ventana de configuración
De la pantalla anterior, seleccionamos las opciones de “grsecurity” requeridas y salvamos el archivo con el botón de guardar.
Ubicados en el directorio /usr/src/linux construimos el paquete .deb
make-kpkg clean
make-kpkg -initrd --revision=ck2 kernel_image
Si no hubo errores se genero el paquete
/usr/src/linux-image-2.6.24-grsec_ck2_i386.deb
Para instalarlo
dpkg -i linux-image-2.6.24-grsec_ck2_i386.deb
Por ultimo descargamos de un mirror de Ubuntu el paquete “gradm2_2.1.11-1_i386.deb” y lo instalamos con “dpkg”.
Reiniciamos el sistema operativo
CONTROL DE ACCESO BASADO EN ROLES (RBAC)
Existen dos tipos de mecanismos de control de acceso usados para prevenir el acceso no autorizado a archivos o información en general: DAC (control de acceso discrecional) y MAC (control de acceso obligatorio). Linux usa por defecto el mecanismo DAC, en el cual el creador del archivo puede definir quien tiene acceso a este.
En DAC un usuario tiene un completo control sobre los objetos que le pertenecen y los programas que ejecuta. Así mismo, el programa ejecutado por un usuario tendrá los mismos permisos de ese usuario que lo esta ejecutando.
Lo anterior implica que la seguridad del sistema depende de las aplicaciones que se están ejecutando y por lo tanto, cuando se produce una vulnerabilidad de seguridad en una aplicación, ésta afecta a todos los objetos a los que el usuario tiene acceso. Así, si la aplicación es ejecutada por “root”, el atacante puede obtener los máximos privilegios en el sistema, comprometiendo la seguridad global.
Un sistema MAC fuerza a que todos sigan las reglas establecidas por el administrador. En este modelo existe una política de seguridad definida por el administrador y que los usuarios no pueden modificar. Esta política va más allá de establecer propietarios de archivos, define contextos, en donde se indica cuando un objeto puede acceder a otro objeto.
La implementación MAC de “grsecurity” es llamada RBAC. Esta herramienta asocia roles a cada usuario, cada rol define que operaciones pueden ser llevadas a cabo sobre ciertos objetos. Dada una colección bien escrita de roles y operaciones, los usuarios estarán restringidos a hacer solamente aquellas tareas que el administrador le dice que pueden hacer.
TRABAJANDO CON RBAC
“gradm2” es el programa que permite administrar y mantener políticas para el sistema. Con el se puede activar o desactivar el sistema RBAC, cambiar su rol y configurar una contraseña para el modo de administrador.
Para introducir una contraseña para el administrador:
gradm2 -P admin (ingresar contraseña del rol administrador)
hecho lo anterior podemos activar el sistema RBAC con:
gradm2 -E
La política predeterminada esta definida en “/etc/grsec2/policy” y es bastante restrictiva ya que siendo usuario “root” no podemos ver el directorio “/etc/grsec2/”, la siguiente instrucción:
cd /etc/grsec2/
dará por resultado que no se encuentra el archivo o directorio.
O bien, una instrucción como “ifconfig” no será capaz de modificar las características de las interfaces con el modo RBAC habilitado.
El usuario “root” no puede modificar la interfaz eth0
Para desactivar el sistema RBAC
gradm2 -D (ingresar la contraseña definida para el administrador)
Para conocer en que estado se encuentra RBAC
gradm2 -S
LISTAS DE CONTROL DE ACCESO
El sistema de control de acceso MAC de “grsecurity” esta implementado con listas de control de acceso ACL's, el administrador define restriciones sobre sujetos (recursos, procesos, archivos, etc.). Para cualquier evento, el “kernel” verifica las ACL's de MAC y las definidas en el estandar de Linux que manejan objetos.
ACL estandar de Linux (sentencia “getfacl”)
Objeto archivo “home/daniel”, objeto usuario y grupo “daniel”
Estructura de una ACL de “grsecurity”:
ARCHIVO DE POLITICAS PREDETERMINADO
“/etc/grsec2/policy”
Como se menciono anteriormente, la politica definida en el archivo predeterminado es bastante restrictiva. Si RBAC esta activo ningun usuario podrá acceder al programa “dmesg” y auditar el sistema.
“dmesg” operacion no permitida
ACTUALIZANDO LAS POLITICAS
La manera mas sencilla de actualizar las politicas para la ejecución de un determinado programa es a través del modo de aprendizaje de “grsecurity” en lugar de hacerlo manualmente.
Para el modo de aprendizaje, será necesario desactivar RBAC temporalmente desde la consola utilizando:
gradm2 -a admin
gradm2 -D
Como ya podemos ver el directorio y los archivos de “grsecurity”, añadimos al final del archivo “/etc/grsec2/policy” una entrada como la siguiente
Lo anterior oculta el directorio raiz a el proceso “dmesg” y elimina cualquier privilegio que pueda necesitar. La “l” junto al nombre del programa significa que se usará el modo de aprendizaje
Activamos RBAC en modo de aprendizaje
gradm2 -L /etc/grsec/learn_config -E
Ejecutamos el comando “dmesg”
dmesg
Si la orden tiene exito, “grsecurity” crea las entradas correpondientes en el registro de aprendizaje. Entonces utilizaremos “gradm2” para generar las ACL's para el programa “dmesg”, a partir de los datos obtenidos.
Desactivamos RBAC y el modo de aprendizaje
gradm2 -a admin
gradm2 -L /etc/grsec2/learn_config -O /etc/grsec2/learning.dmesg
Se creo el archivo “learning.dmesg” con las politicas para “dmesg”
Sustituimos en “/etc/grsec2/policy” la directiva de aprendizaje que inlcuimos para “dmesg” por el contenido de “learning.dmesg” y volvemos a inicar RBAC.
Ahora para “root”, es posible ejecutar el comando “dmesg” con RBAC activo.
Por ultimo definimos dentro de nuestras politicas que también el usuario “daniel” tenga derecho a auditar el sistema con “dmesg”.
Agregando al usuario “daniel”
Esta secuencia se puede seguir para cada programa que necesite permisos especiales para operar.
Mientras “grsecurity” este en modo de aprendizaje debemos asegurarnos de probar todas las operaciones que se vayan a necesitar para que se detecte que llamadas utilizan los procesos o que archivos del sistema se requieren.
CONCLUSION
“Grsegurity” brinda la posibilidad de crear un sistema que proporciona a cada proceso unicamente los permisos que necesita para hacer su trabajo: ni más, ni menos. “Grsegurity” brinda un control muy preciso sobre todo lo que se puede hacer en un sistema.
No hay comentarios:
Publicar un comentario