1. -Introducción

2. -Kernel Linux base

2.1 -Análisis

2.1.1 -DAC

2.1.2 -RAM

3. -El TCSEC

3.1 -Sistemas D

3.2 -Sistemas C

3.2.1 -Sistemas C1

3.2.2 -Sistemas C2

3.3 -Sistemas B

3.3.1 -Sistemas B1

3.3.2 -Sistemas B2

3.3.3 -Sistemas B3

3.4 -Sistemas A1

4. -RSBAC

4.1 -Introducción

4.2 -Modelos (teoría)

4.2.1 -MAC

4.2.2 -RC

4.2.3 -AUTH

4.2.4 -ACL

4.2.5 -CAP

4.2.6 -FF

4.2.7 -RES

4.2.8 -PAX

4.2.9 -JAIL

5. -Política de seguridad

6. -ToDo

Bibliografía

Capítulo 1.
Introducción.

Este artículo está orientado a cubrir un hueco importante en relación a un tema muy de
actualidad, la seguridad. Si bien no es una solución de seguridad lo que voy a realizar, sí trata de
ser una base para que todos vosotros tengáis algo en lo que apoyaros.

Asegurar un sistema es una ardua tarea, existen millones de archivos en un sistema GNU/Linux,
miles de binarios y otros tantos de librerías, cada uno de ellos sujeto a vulnerabilidades
esperando ser explotadas. Se puede decir (y de seguro que alguien lo dijo) que es una
guerra en la que el administrador tiene todas las de perder, su reputación y la confianza
de quienes confían en él penden de un hilo sujeto por unas pocas líneas de código
escrito por posibles genios con ética y desgraciadamente poseídas por scripts kiddies
ineptos.

La documentación relacionada con RSBAC es muy escasa, y por desgracia para nosotros eso es un impedimento para implementar el que es para mí el mejor sistema de seguridad
existente hasta la fecha. De los otros colosos, GrSecurity, LIDS y SeLinux tan sólo este último puede proporcionar un grado de seguridad semejante a RSBAC, pero la tecnología en la que se basa, el Type Enforcement fue patentada por Secure Computer Corporation y por lo tanto ha sido el motivo de su descarte por mi parte. El artículo que aquí empiezo
pretende que tengáis un soporte tanto teórico como práctico en la implementación de RSBAC y por lo tanto deseo que os sea de utilidad.

No cubriré la instalación de RSBAC, puesto que este tema sí está apropiadamente
documentado, sin embargo sí explicaré cómo es el sistema de seguridad de un linux de base para que os sea más simple distinguir las diferencias con RSBAC, también tocaré el famoso libro naranja, origen del
TCSEC y por supuesto prácticamente todo RSBAC salvo los modelos DAZ y PM y UM que no voy a utilizar por ahora y que añadiré en futuras revisiones a pesar de ser tres grandísimos módulos (el Privacy Model basado en las ideas de Simone Fischer-Hübner es una de las mayores referencias del sector).

Capítulo 2.
Kernel Linux base

El kernel linux por defecto basa su seguridad en una relación de confianza, da potestad a sus usuarios para elegir quien puede tener acceso a objetos de su propiedad confiando en su juicio y buen hacer. El DAC (siglas inglesas de Control de Acceso Discreccional) como tal puede ser perfecto. El problema es que para evitar que los usuarios añadan usuarios o pongan a escuchar demonios en puertos bajos hubo la necesidad de marcar ciertas tareas como privilegiadas, y por ello existió la necesidad de crear un usuario situado por encima de los demás. Dicho usuario, el administrador, root o UID 0, al cuál el kernel le ha concedido unos privilegios especiales o capabilities para mantener su estatus y permitirle realizar dichas tareas (para lo cuál es imprescindible a veces saltarse el DAC).

El problema es que esas “capacidades” extras poseídas por root son utilizadas siempre aunque no sean
necesarias (nadie o casi nadie utiliza la “libcap”. Un demonio que necesite escuchar en un puerto bajo no debería poder dar de baja el cortafuegos) y por lo tanto un proceso vulnerable explotado para ejecutar código malicioso no sólo obtendría los privilegios mínimos, sino que conseguiría el control total sobre el sistema y es aquí donde reside el principal punto vulnerable de Linux.

Análisis

2.1.1. El DAC

El DAC funciona a uno de dos niveles, a nivel de ínodos en el sistema de archivos o a nivel de
vfs (Virtual File System). Si el sistema de archivos no soporta permisos (como es el caso de vfat) el vfs se los asigna genéricos. Si realmente los soporta utiliza la información obtenida del ínodo para ello.

En el ínodo de sistemas de archivos compatibles se guardan entre
otros datos el usuario dueño (no el nombre, su UID o identificador de usuario, ya que dicho mapeo lo realiza la glibc a través del /etc/passwd) y el grupo dueño del archivo a través de su GID y los permisos de otros no UID dueño y no GID dueño.

El DAC se extiende a los procesos de un modo muy simple, si el archivo es un binario y
éste es ejecutado, el UID y el GID de quien lo ejecuta se heredan al proceso recién
creado (ved la salida de un cat /proc/self/status) y sus permisos sobre el sistema de archivos son acordes a los que dicho usuario tendría. Como excepción a la regla están los procesos SUID y SGID que cambian el identificador de usuario/grupo efectivo al usuario/grupo dueño del binario y que pueden mejorar/mermar la
seguridad de todo el sistema (disminuyendo privilegios/aumentándolos).

2.1.2. RAM

Linux utiliza el modo protegido para aislar los procesos y los bit supervisor en segmentos para
protegerse, además de una mezcla de segmentación/paginación como forma de manejo de la memoria
virtual (la memoria virtual no es la swap, la memoria virtual es una abstracción de la memoria real física que aprovechándose de la paginación/segmentación permite direccionar hasta 4 Gb de RAM en arquitecturas de 32 bits aunque la máquina no tenga dicha capacidad, ésta es la que permite que se creen particiones/archivos de intercambio o swap. Por lo tanto la memoria virtual no es ni más ni menos que la suma RAM física + SWAP).

Primero, para aislar el kernel, linux crea cuatro segmentos: dos de datos DS y dos de código CS que abarcará el código ejecutable. Uno de cada será de uso exclusivo del kernel y abarcará
direcciones entre 0xc0000000 a 0xffffffff (1 gigabyte) marcado con DPL 0 (ring 0) y otro de
datos y código para el espacio de usuario que irá desde 0x00000000 a 0xbFFFFFFF
(3 Gigabytes) marcados con DPL 3 (ring 3). Para realizar la comunicación entre el
espacio de usuario y el kernel, linux pone a disposición dos interfaces de llamadas al
sistema, una a través de las lcalls para mantener compatibilidad con otros UNIX (y
que no son ptraceables algo muy grave si se utiliza por ejemplo user-mode-linux) y la
otra a través de una interrupción por software 0x80 que es la utilizada normalmente.
Cuando ésto se realiza, el kernel asciende el CPL (Current Priviledge Level) del proceso
de 3 a 0 y realiza la petición en un ambiente controlado retornando después a CPL
3.

En GNU/Linux existen varias formas de acceder al contenido de ring 0, una es mediante un
dispositivo especial de caracteres, con major 1 y minor 2 llamado /dev/kmem. Éste contiene toda
la memoria virtual del núcleo. Como tal pueden ser sobreescritas funciones del núcleo allí

presentes vía open(2), read(2) y write (2). Otro dispositivo, /dev/mem de major 1 y minor 1
contiene toda la memoria física (no virtual) del sistema, por lo tanto también existe posibilidad
de parcheo a través suyo aunque es mucho más engorroso (ambas controladas por
CAP_SYS_RAWIO).

También es posible hacerlo sin llamadas de entrada/salida. Directamente mapeando kmem
vía mmap(2) con los flags PROT_WRITE para permitir la escritura y MAP_SHARED para que
los cambios hagan efecto (si se utiliza MAP_PRIVATE en vez MAP_SHARED se harán los
duplicados en una copia privada siguiendo el principio del Copy On Write (COW)). Copy
On Write es una tecnología que permite por un lado hacer el sistema más estable,
puesto que impide que los procesos escriban en direcciones compartidas con otros
procesos y por otro ahorra recursos ya que se comparten recursos hasta que es necesaria la
escritura. Cada proceso comparte con su progenitor todo el espacio de memoria que utiliza
siempre y cuando sea en modo lectura. Si necesita escribir en él se hace su propia
copia.

También se puede acceder al ring 0 a través de la interfaz del cargador de módulos. Cuando se
compila un kernel con el soporte de módulos activado a lo que se está dando soporte realmente es
a una serie de llamadas al sistema como init_module. Estas llamadas al sistema permiten que un
usuario poseedor de CAP_SYS_MODULE cargue o descargue binarios elf en direcciones de
memoria por encima de 0xc0000000 o lo que es lo mismo en ring 0. Un módulo (en “teoría”)
sólo es capaz de ver y usar las funciones del kernel que están exportadas (en pocas palabras
presentes en /proc/ksyms, fichero que por cierto desaparece si deshabilitamos los módulos en el
kernel) aunque se ha demostrado que a pesar de una función de no estar exportada (como la tabla
de llamadas al sistema o syscall_table en los kernel 2.6) aún es posible determinar su localización
y sobreescribirla.

Aún cuando no exista el fichero ksyms siempre suele existir el System.map que contiene todas
las funciones del kernel junto a sus direcciones, ya estén exportadas o no. Por lo tanto es
aconsejable guardar una copia de seguridad en un disquete o en un cd y borrar dicho archivo del
disco duro ya que en caso de compromiso este fichero servirá de base de datos para localizar
funciones importantes del kernel y parchearlas. El guardar una copia es más que nada porque
normalmente si cambia una función (por un parcheo en caliente) su localización en memoria
cambia también y por lo tanto también podremos comprobar la existencia de compromiso del
núcleo en este caso.

Por último existe la posibilidad de modificar variables de ring 0 a través del sistema de
archivos proc. Éste es sólo un espejo del sistema en el que algunas entradas apuntan directamente
a variables del kernel (como el acceso al cap-bound controlado por CAP_SYS_MODULE), y que
por lo tanto permite modificar directamente dicho ring.

[page_break]

Capítulo 3
El TCSEC

El TCSEC (Trusted Computer System Evaluation Criteria), también llamado libro naranja, surgió a finales del 1985 con el objetivo de servir de referencia para la clasificación y evaluación de la
fiabilidad/seguridad de sistemas computacionales, debido a la aparición de una directiva del departamento de defensa de EEUU en el que indicaba que todas sus partes debían cumplir con dichos criterios para su uso.

Para clasificar los sistemas utiliza una nomenclatura que varía de sistemas tipo D (aquellos
que no cumplen con los requisitos mínimos de seguridad) hasta el A (sistemas cuya protección ha sido verificada matemáticamente). Así se evalúan seis aspectos fundamentales englobados en tres partes bien diferenciadas:

• Política de seguridad: El sistema debe tener unas reglas que controlen y regulen el
  acceso de los distintos sujetos a la información presente en ella (Security Policy).
  Así como que debe proveer un mecanismo de marcaje de la información contenida
  en ella para su clasificación (Marking).
• Responsabilidad: Todos los usuarios deben ser identificados. Dicha identificación y
  autorización debe ser mantenida por dicho sistema y asociada con todos los actos
  que realicen hechos relevantes para la seguridad (Identification). Todos aquellos
  actos relevantes desde el punto de vista de la seguridad deben ser registrados
  para poder reclamar responsabilidades, asegurando su protección de modificación
  no-autorizadas (Accountability).
• Aseguramiento: El sistema de asegurar el cumplimiento tanto de las partes de
  Política de seguridad y de responsabilidad proveyendo mecanismos que controlen
  dichas acciones de forma segura (Assurance). Los mecanismos de seguridad deben
  estar continuamente en funcionamiento, durante toda la vida del sistema (Continuous
  protection).

Así se realiza la clasificación de los sistemas:

3.1. Sistemas D (Protección Mínima):

En esta clasificación caen todos aquellos sistemas que no cumplen con todos los requisitos para
entrar en una clasificación superior.

3.2. Sistemas C (Protección Discreta):

3.2.1. C1: Protección de seguridad discreccional.

El sistema debe definir y controlar el acceso de los usuarios a los objetos. También debe permitir a los usuarios controlar el acceso a dichos objetos a través de listas de control de accesos (dueño,
grupos y otros). Para ello se requiere un sistema de autentificación vía contraseña para identificar a los usuarios. También es necesario que el código y las estructuras de datos corran en un dominio distinto del de los usuarios (ring 0).

3.2.2. C2: Protección de acceso controlado

Se necesita además de lo contenido en el C1 un aumento de la granularidad, es decir,
extender dueño/grupo/otros a listas de control de accesos individuales y aumentar la flexibilidad. El sistema debe ser capaz de registrar los accesos de los usuarios a los objetos del sistema y proteger dichos registros contra accesos no autorizados. Política de negación por defecto (el sistema no debe permitir el acceso antes de que su dueño asigne los permisos)

3.3. Sistemas B (Protección mandataria):

Todos los sistemas B requerirán de las capacidades de los C y necesitarán del uso de etiquetados de sensibilidad basado en el modelo de Bell-LaPadula. Empezamos a hablar de sistemas fiables. A
indicar que el modelo de Bell-LaPadula solo protege la confidencialidad de los datos y no su integridad (modelo BIBA) pero es en el que se basa en exclusiva el TCSEC. Por lo tanto, un sistema que utilice los dos métodos será por defecto más seguro que uno que utilice tan sólo el modelo de Bell-LaPádula aunque la calificación obtenida en el TCSEC será la misma.

3.3.1. B1: Protección mediante etiquetas

Se le asigna a los objetos una etiqueta con un nivel de sensibilidad y a los sujetos otra con su nivel de seguridad sólo modificable ambos por el TCB (no-discreccional). El acceso a la información
está controlado por ella. Aunque el Control de Acceso Discreccional permita el acceso a un recurso, no garantiza su disponibilidad si el MAC no lo confirma.

3.3.2. B2: Protección estructurada.

Se implementa una política de menor privilegio en el kernel, se realiza un modelo formal de seguridad. Todos los objetos, incluyendo dispositivos y canales de entrada/salida están etiquetados.

3.3.3. B3: Dominios de seguridad

Rediseño del TCB, debe ser lo más pequeño posible, cualquier código innecesario debe ser excluido de él, además debe ser muy modular. Se amplían las capacidades de registro para señalar eventos relacionados con la seguridad.

3.4. Sistemas A (Protección verificada):

3.4.1. A1: Diseño verificado

Funcionalmente es equivalente a un sistema B3, el sistema y su modelo matemático han sido completamente analizados y probados.

Capítulo 4
RSBAC
4.1. Introducción.

Rsbac es una extensión para el kernel línux creada por Amon Ott, es decir, un parche que
nos permite entre otras cosas elegir entre varios modelos de seguridad diferentes o complementarlos. No sólo agrega controles de accesos, también añade una extensión que provee PaX y que hace al sistema más seguro contra exploits(mediante la conversión de la stack y heap a no-ejecutables además de con medidas de aleatorización). También añade una opción JAIL para aislar procesos y de una impresionante capacidad de registro que comentaré después.

¿Por qué rsbac y no otros?

Bien, las opciones que miré eran LIDS, SELinux, GRSecurity y MedusaDS9. SELinux la
descarté por motivos de patentes, ya que aunque la empresa dueña de la patente del Type Enforcement, Secure Computing Corporation, ha dejado claro que no la utilizaría para mí no es libre.

LIDS no tiene soporte de roles y el de GRSecurity es muy básico a mi modo de ver por lo
tanto no son tan flexibles como rsbac. También se podría decir que LIDS lleva los modelos CAP,
ACL y algo de JAIL de rsbac (equiparablemente hablando) por lo que carece (para mí) de muchas
otras características. Aún así ambas son unas alternativas dignas de elogio. A pesar de todo la
capacidad de GrSecurity en cuanto su capacidad de aprendizaje de políticas es actualmente muy
superior a la de RSBAC.

MedusaDS9
es otra historia, teóricamente permite implementar cualquier modelo de seguridad, el problema es
que lleva bastante tiempo en estado “vegetativo”.

4.2. Modelos (teoría).

Rsbac se diseñó para ser extensible y poder añadir así otros modelos de seguridad adicionales o si
queremos añadir el nuestro propio. A grosso modo su funcionamiento se puede decir que es simple.
Cuando una aplicación solicita el uso de una llamada al sistema (como el unlink de rm) ésta es
interceptada por una parte de rsbac denominada AEF (Access EnForcement). Ésta envía una petición (o llamadas al sistema, como prefiráis a la parte ADF (Access Decision Facility), preguntando qué debe hacer. El ADF pasa la petición por los diferentes modelos (MAC, CAP, FF...) y a través de la información obtenida del ACI
(Access Control Information, tercera y última parte de RSBAC) decide si la petición debe o no ser rechazada notificando su decisión al AEF (la cuál descart llamada o no) y registrando la petición si es preciso. Sólo se necesita que un modelo la rechace para denegarla.

Este modelo se basa en el Generalized Framework Access Control (GFAC) de Brahms y La
Pádula lo que permite, entre otras cosas mejorar la portabilidad, debido a que no todo el código es
dependiente del sistema operativo (el AEF sobretodo lo es).

[page_break]

Sujetos, peticiones y objetos.

Varias veces se verá a lo largo de este artículo las palabras sujeto (Subject), objeto (object o
target) y petición (request). He aquí los principales:

• Objetos:
  
  FILE: Archivos y dispositivos, identificados por el dispositivo en el que se encuentra y por su
  ínodo.

  DIR: Directorios. Se identifican análogamente a los archivos.

  FIFO: Tuberías.

  DEV: Dispositivos, identificados por block/char:major:minor.

  IPC: Sistemas de comunicación entre procesos, como semáforos.

  SCD: Datos del sistema importantes, como puede ser el acceso a kmem (memoria del kernel).

  USER: Usuarios.

  PROCESS: Procesos.

  NETDEV: Dispositivo de red, identificado por nombre.

  NETTEMP: Plantillas de red. Sirven para distinguir las distintas redes del sistema (local,
  internet...) y los tipos de sockets utilizados (AF_INET, AF_UNIX...)

  NETOBJ: Objetos de red.

  NONE: Ninguno asociado a este objetivo.

  FD: Simplifica el uso de herramientas en espacio de usuario ya que unifica FILE y DIR y
  obliga a la herramienta a elegir la apropiada.




• Peticiones (request):

  ACCEPT: Acepta una conexión remota. Afecta a NETOBJ.

  ADD_TO_KERNEL: Añade un módulo al kérnel. Afecta a objetos NONE.

  ALTER: Cambia la información de control de IPC. Afecta a objetos IPC.

  APPEND_OPEN: Abre para añadir. Afecta a objetos FILE, DEV e IPC.

  BIND: Se enlaza a una dirección de red a un socket. Afecta a NETDEV, NETOBJ.

  CHANGE_GROUP: Cambia de grupo dueño. Afecta a IPC, PROCESS y NONE.

  CHANGE_OWNER: Cambia el dueño. Afecta a FILE, DIR, IPC, FIFO, PROCESS, NONE.

  CHDIR: Cambia de directorio activo. Afecta a DIR.

  CLONE: Crea duplicados de procesos. Afecta a PROCESS.

  CLOSE: Cierra lo indicado. Afecta a FILE, DIR, FIFO, DEV, IPC, NETOBJ.

  CONNECT: Conecta a un puerto remoto. Afecta a NETOBJ.

  CREATE: Crea un nuevo objeto. Afecta a DIR, IPC, NETTEMP, NETOBJ.

  DELETE: Borra un objeto. Afecta a FILE, DIR, FIFO, IPC.

  EXECUTE: Ejecuta un proceso. Afecta a FILE.

  GET_PERMISSION_DATA: Obtiene los permisos línux. Afecta a FILE, DIR, FIFO.

  GET_STATUS_DATA: Obtiene información. Afecta a FILE, DIR, FIFO, IPC, SCD,
  NETDEV.

  LINK_HARD: Crea enlaces duros. Afecta a FILE, DIR, FIFO.

  LISTEN: Pone a escuchar en un socket. Afecta a NETOBJ.

  MAP_EXEC: Carga una librería en memoria. Afecta a FILE, NONE.

  MODIFY_ACCESS_DATA: Cambia la información de acceso. Afecta a FILE, DIR, FIFO.

  MODIFY_ATTRIBUTE: Cambia atributos de rsbac. Afecta a TODOS.

  MODIFY_PERMISSIONS: Cambia permisos. Afecta a FILE, DIR, FIFO, SCD.

  MODIFY_SYSTEM_DATA: Cambia atributos del sistema. Afecta a SCD, NETDEV.

  MOUNT: Monta sistemas de archivos. Afecta a DIR, DEV.

  NET_SHUTDOWN: Afecta a NETOBJ.

  READ: Lee de... Afecta a DIR, NETTEMP, FILE, FIFO, DEV, IPC, NETOBJ.

  READ_ATTRIBUTE: Lee atributos de rsbac. Afecta a TODOS.

  READ_OPEN: Abre en modo lectura. Afecta a FILE, FIFO, DEV, IPC.

  READ_WRITE_OPEN: Abre en modo lectura-escritura. Afecta a FILE, FIFO, DEV, IPC.

  RECEIVE: Recibe de un punto remoto de la red. Afecta a NETOBJ.

  REMOVE_FROM_KERNEL: Elimina un módulo. Afecta a NONE.

  RENAME: Renombra. Afecta a FILE, DIR, FIFO.

  SEARCH: Búsqueda. Afecta a DIR, SYMLINK.

  SEND: Envía a un punto remoto de la red. Afecta a NETOBJ.

  SEND_SIGNAL: Envía una señal (SIG). Afecta a PROCESS.

  SHUTDOWN: Apaga reinicia el sistema. Afecta a NONE.

  SWITCH_LOG: Cambia atributos de registro de rsbac. Afecta a NONE.

  SWITCH_MODULE: Añade/quita módulos del ADF. Afecta a NONE.

  TERMINATE: Fin de proceso. Afecta a PROCESS.

  TRACE: Enlaza a un proceso. Afecta a PROCESS.

  TRUNCATE: Trunca un archivo. Afecta a FILE.

  UMOUNT: Desmonta un sistema de archivos. Afecta a DIR, DEV.

  WRITE: Escribe en.... Afecta a DIR, SCD, FILE, FIFO, DEV, IPC-sock.

  WRITE_OPEN: Abre para escritura. Afecta a FILE, FIFO, DEV, IPC.

  Un sujeto es normalmente un proceso cargado por un usuario. Cada petición puede
  englobar a una o más llamadas al sistema, es decir, CLONE engloba tanto a fork
  como a clone.

Modelos del ADF y características extra.

Realmente modelos de control de acceso serían en sí el MAC, RC, CAP y ACL. El resto se
utilizarían para complementarlos, ya sea a través del FF (File Flags el equivalente
aproximado a chattr), PAX o mediante la imposibilidad de ejecutar llamadas a SGID o SUID
(AUTH).

4.2.1. MAC

Este modelo basado en el desarrollo de Bell y La Padula implementa un control de accesos basado
en anillos parecido a los ring de un sistema MULTICS. Es un modelo muy complejo y difícil de
entender, por lo tanto trataré de explicarlo y hacerlo lo más simple posible el funcionamiento de
éste:

Definiciones

Sujeto o s(Subject): Usuario o proceso que requiere el acceso.

Objeto u o(Object): Todo aquello a lo que se necesita acceder.

Modo u a(Mode): Tipo de acceso, como lectura, escritura, sólo añadido(append) o
ejecución.

Estado(State):Yo lo entiendo como la petición en sí, es decir. El modelo indica que es un
triplete (b(s,o,a), M, f(fs,fc,fo)) siendo b el modo de acceso requerido, M los permisos existentes
en el sistema y f el nivel de seguridad asignado, fs es el nivel máximo que el sujeto puede
tener (como confidencial, secreto etc), fc es el nivel actual y fo el nivel del objeto. Es
claro que el nivel máximo no puede ser excedido por el actual (es decir fs domina a
fc).

Para garantizar o denegar el acceso se pasa la petición por tres “filtros”:

• Propiedad de seguridad simple (ss-property): Si el modo de acceso existente en b es
  lectura o escritura y el nivel del objeto es inferior al nivel máximo del sujeto (fs)
  entonces el acceso es permitido.
• Propiedad estrella (*-property):
  
  Si a es escritura: El nivel actual (fc) del sujeto debe ser igual al nivel del objeto (fo).
  Para el resto de accesos el nivel del sujeto debe dominar al del objeto. Con ésto
  se garantiza que ningún nivel privilegiado pueda escribir en uno inferior (no puede
  escribirse desde un nivel secreto a un no-clasificado por ejemplo, también llamado
  no-write-down). Esta propiedad sólo puede ser saltada si colocamos al sujeto como
  fiable (trusted).
• Propiedad de seguridad discreccional (ds-security): Se acepta si el modo de acceso
  “a” está presente en “M”.

Por lo tanto se puede resumir en que una petición sólo será aceptada si el modo de acceso está
presente en el sistema, si el nivel de seguridad del sujeto es mayor o igual que el del objeto y si
es del tipo escritura que el nivel del sujeto sea igual al del objeto (a no ser que sea
trusted).

Ahora voy a poner un ejemplo que a lo mejor os servirá para entenderlo mejor: un
usuario “jesús” de nivel máximo no-clasificado quiere acceder a un archivo llamado
contabilidad de nivel confidencial en modo de lectura. Es decir aplicamos b(s,o,a), M,
f(fs,fc,fo):

(“jesus”, “/opt/contabilidad”, r), rx, (no-clasificado,no-clasificado,confidencial)

No cumpliría con la ss-property puesto que el nivel del objeto es mayor que el del
usuario jesús y por lo tanto sería rechazada la petición. Sí cumpliría por ejemplo la
condición ds-property ya que en los permisos del fichero para para ese usuario es de
rx.

4.2.2. RC

Éste es para mí el último modelo (aparentemente) complicado y que sigue a un modo de pensar
bastante simple. El RC se basa en tres partes: roles, tipos y objetos. Un rol puede ser compatible
con una serie de tipos para acceder a un determinado objeto (archivo, proceso, dispositivo...) pero
no con otros. Podemos por ejemplo crear el rol chivato, el cuál sólo podría acceder a un subtipo
llamado archivos_log (todos los archivos del directorio /var/log, nuestro objeto) del tipo FD
(File/Dir) con los permisos de sólo-lectura. No tendría ningún tipo de privilegio extra. Nuestro
administrador podría, por ejemplo no ser compatible con el tipo archivos_log y por lo tanto no
acceder a ellos pero sí ejercer sus funciones creando cuentas, montando dispositivos
etc.

Esta disgregación de responsabilidades no puede realizarse en un GNU/Línux convencional
ya que root es capaz de hacerlo todo. Con rsbac podríamos contratar a un administrador por un
lado y a un auditor de registros por otro y que ejercieran sus funciones de forma totalmente
independiente.

Cuando un usuario se identifica en el sistema (cada setuid) posee un rol inicial al que
pertenece y que contiene una serie de permisos. Dicho rol puede verse alterado de varias formas
por ejemplo:

Puede cambiar a un rol compatible. Si no queremos que los usuarios pongan a escuchar
demonios a través de LISTEN y BIND con su rol por defecto, podemos permitirles que lo hagan
en un entorno mucho más controlado haciendo que cambie a un rol mucho menos privilegiado
compatible con el suyo. El rol al que cambia no tiene que ser compatible con el anterior y por lo
tanto no tiene por qué ser capaz de cambiar de vuelta.

La otra manera de hacer esto mismo es con el rol forzado. Podemos asignar a un binario un rol
forzado al que el proceso cambiará cuando sea ejecutado por un usuario.

Unos roles pueden administrar a otros roles siempre y cuando así esté especificado. Es decir
el rol supervisores, podría ser capaz de administrar los roles de técnicos o de trabajadores y a su
vez ser administrado por el rol gerente (admin roles).

También se puede hacer que el rol gerente pueda asignarle a un usuario introducido en el rol
técnico el grado de supervisor si así se especifica (assign roles)

4.2.3. AUTH

Pequeño pero muy importante. Este modelo controla la capacidad de los procesos para cambiar su
UID, como pudiera ser a través de SUID, denegándolas por defecto y sirve de soporte para los
demás. Si realmente fuera necesario permitiría incluso especificar a que UID podría
cambiar. Ésto se realiza a través de las utilidades de rsbac a través de auth_may_suid y
auth_may_set_cap.

Cuando hablamos del UID debemos distinguir entre tres UID y tres GID, el real ID, el ID
efectivo y el fs ID. El primero es el UID real de usuario. Si el usuario sufre un suid el ID

efectivo cambia al del suid y así también lo hace el fs ID (a nivel de permisos del
sistema de archivos) manteniendose intacto el id real. Auth es capaz de controlar los
tres.

4.2.4. ACL

Éste modelo es para mí, con mucho, el más flexible de todos. Permite crear listas de control de
accesos individuales para todos los gustos. Permite extender el control ya no sólo a usuarios y
grupos, sino también a roles y su forma de acceder a todos los objetos y con todas las peticiones
disponibles. Crea un permiso especial, supervisor que engloba todos los permisos y que sólo
posee el oficial de seguridad.

4.2.5. CAP

Basado en las linux capabilities. Este modelo aprovecha la capacidad de disgregación de
privilegios del propio kernel linux de base y permite o bien limitar los privilegios de los
programas ejecutados por root (capabilities máximas) o bien conceder a un usuario
no-privilegiado ciertos derechos (capabilities mínimas). Así por ejemplo, un programa como
“login”, sólo necesita de cuatro capabilities para funcionar (CAP_SETUID, CAP_SETGID,
CAP_CHOWN y CAP_FOWNER), por lo tanto es absurdo darle las 29 existentes.

Atención al conceder capabilities mínimas: Si se conceden capabilities mínimas y no se
controla la interfaz de precarga dinámica de librerías (LD_PRELOAD) pueden explotarse de
manera de conceder privilegios a terceros que no se debieran. Para evitarlo colocad el
binario con capabilities mínimas con el bit suid activado (el dueño no tiene por qué ser
root ;) ) ya que así se controla dicho entorno puesto que se realiza un filtrado. Esto
es aplicable a rsbac y a todos los entornos de seguridad que puedan aplicarlas (como
LIDS).

Hasta la versión 1.3 de las utilidades rsbac_admin no está previsto la inclusión de
CAP_LD_PRELOAD para controlar dicho comportamiento anómalo. Ésta guía utiliza la versión
1.2.5 actualmente.

[page_break]

4.2.6. FF

File Flags, este modelo permite marcar ciertos archivos o directorios con atributos especiales, ya
sea sólo_lectura, sólo_ejecución, sólo_búsqueda, sólo_escritura, borrado_seguro, no_ejecución,
no_borrado_renombrado, sólo_añadido, no_montaje. También añade uno más de heredancia o
recursividad.

Las banderas (flags) colocadas a objetivos inválidos son ignoradas (por ejemplo
sólo_búsqueda a un binario)

4.2.7. RES

Controlador de recursos. Permite limitar y garantizar recursos a procesos colocando una cantidad
de recursos mínimos y unos máximos. Es parecido al limitador de recursos de pam
(/etc/security/limits.conf).

4.2.8. PaX

Si hubiera que dar premios a un software en GNU/Linux uno de los mejores candidatos sería sin
duda PaX. PaX es una de esas joyas muy poco conocidas y usadas por el usuario común. Es una
medida de defensa contra la explotación de bugs en el software existente. Implementa
una política de menor privilegio junto al uso de aleatorización frente a los ataques
ret2libc.

Medidas de menor privilegio

Pageexec/Segmexec (P/S)

Ambos se basan en no permitir que existan los privilegios de escritura y ejecución
simultáneamente en zonas de memoria anónimas así como en stack y heap. Pageexec utiliza la
paginación de la arquitectura i386 para conseguir su objetivo mientras Segmexec utiliza la
segmentación. Si se permiten ambos permisos simultáneamente pueden injertarse datos aleatorios
por errores programativos e introducir la dirección de éstos en el puntero de retorno de la pila para
ejecutarlo. Con la lógica de trabajo de Pageexec/Segmexec o se escribe o se ejecuta, nunca los dos
a la vez y por lo tanto dicho ataque no es eficaz.

La pregunta de rigor a hacerse es: ¿Cuál de los dos usar?. La respuesta la tendréis en el bit NX (No
eXecute. Cat /proc/cpuinfo y observar si está disponible).
Si no está disponible lo recomendable es usar Segmexec puesto que no merma el rendimiento
aunque limita el espacio de direcciones que un programa puede usar a un gigabyte y medio por
cada. Ésto es así puesto que divide las direcciones correspondientes al espacio de usuario
(0x00000000 - 0xbfffffff o 3 gigabytes) en dos, el cuál uno de ellos es ejecutable y el otro no
(datos).

En un sistema sin bit NX que use Pageexec, PAX lo emula utilizando los bits supervisor. Si
está disponible no realizará la emulación y por tanto el rendimiento quedará intacto, siendo éste
el sistema recomendado en dichas circunstancias.

Restricciones a mprotect (M)

Dependiente del anterior (sin Pageexec/Segmexec no sirve de nada) restringe las llamadas a
mmap y mprotect para que dichos mapeos sean o sólo escritura (PROT_WRITE) o sólo ejecución
(PROT_EXEC) pero nunca ambos (usuarios de sistemas BSD pueden echar un ojo a
W∧X).

Medidas de aleatorización (ASLR)

Randmmap (R)

Sólo útil para binarios PIE (binarios posición independientes o lo que es lo mismo binarios que
pueden ser mapeados en cualquier lugar (desde 0x00000000 hasta 0xbfffffff) o ET_DYN (man scanelf). Aleatoriza las direcciones en las que se mapean los binarios (cat /proc/self/maps).
Éste es el método recomendado puesto que la aleatorización es más efectiva. Ayuda contra los
ataques retorno a la librería C.

Randexec (X)

Añade aleatorización (en menor grado que Randmmap) a binarios no posición independiente o
ET_EXEC. Su función es análoga a la anterior, aunque algo menos efectiva. Es recomendable
compilar Y enlazar como binarios ET_DYN. En sistemas mixtos usad ambos.

Mi sistema está configurado con los Flags por defecto PeMRXS y
usando Pageexec por lo tanto el efectivo es PeMRxs (no tengo binarios
ET_EXEC). (cat /proc/self/status)

Paxtest

Paxtest es una herramienta que permite probar PaX para observar los resultados. Un sistema
protegido con PaX daría más o menos lo siguiente:

Executable anonymous mapping : Killed

Executable bss : Killed

Executable data : Killed

Executable heap : Killed

Executable stack : Killed

Executable anonymous mapping (mprotect) : Killed

Executable bss (mprotect) : Killed

Executable data (mprotect) : Killed

Executable heap (mprotect) : Killed

Executable stack (mprotect) : Killed

Executable shared library bss (mprotect) : Killed

Executable shared library data (mprotect): Killed

Writable text segments : Killed

Anonymous mapping randomisation test : 17 bits (guessed)

Heap randomisation test (ET_EXEC) : 13 bits (guessed)

Heap randomisation test (ET_DYN) : 23 bits (guessed)

Main executable randomisation (ET_EXEC) : No randomisation

Main executable randomisation (ET_DYN) : 15 bits (guessed)

Shared library randomisation test : 17 bits (guessed)

Stack randomisation test (SEGMEXEC) : 23 bits (guessed)

Stack randomisation test (PAGEEXEC) : 23 bits (guessed)

Return to function (strcpy) : paxtest: bad luck, try different compiler options.

Return to function (memcpy) : Vulnerable

Return to function (strcpy, RANDEXEC) : paxtest: bad luck, try different compiler
options.

Return to function (memcpy, RANDEXEC) : Vulnerable

Executable shared library bss : Killed

Executable shared library data : Killed

Como podréis ver muchos de los “ataques” son matados por PaX y por lo tanto ineficaces.
Como os dije con anterioridad no utilizo randexec por lo tanto no me aleatoriza los
ejecutables ET_EXEC. Fijáos también cómo utiliza más bits aleatorios en ET_DYN que en
ET_EXEC.

Por último ese retorno a función memcpy vulnerable: Ese indica que PaX no es infalible y que
no debe ser la única protección dada. Deberéis utilizar SSP/ProPolice (flag -fstack-protector-all de
gcc) para compilar todo el sistema con dicho flag.

4.2.9. JAIL

El módulo JAIL implementa una nueva llamada al sistema rsbac_jail() que aumenta
la potencia de chroot aplicando restricciones a los procesos de su interior. Tal como
indica la documentación de dicho módulo los procesos en el interior de la cárcel no
pueden:

• Añadir o quitar módulos del kernel.
• Apagar o reiniciar el sistema.
• Montar o desmontar sistemas de archivos.
• Crear sockets no UNIX o INET.
• Utilizar IP’s distintas a las asignadas.
• Crear sockets del tipo INET RAW.
• Acceder a mecanismos de comunicación entre procesos (IPC) fuera de la cárcel.
• Crear dispositivos.
• Mandar señales a procesos de fuera de la cárcel u obtener información de ellos.
• Incluir SUID, SGID flags.
• Cambiar los límites de recursos.
• Modificar atributos del sistema (SCD).
• Dar de baja el DAC.
• Cambiar el estado de RSBAC.

BUGS:

Un bug a mi modo de ver existe en esta versión:

Cualquier usuario sin privilegios puede dar de alta un módulo del ADF (no quitarlos)
simplemente llamando a switch_module si:

El módulo está soportado en el kernel.

El módulo no está corriendo en la actualidad.

Consejo: Restringir el añadido de módulos RSBAC al vuelo a través de la configuración del
kernel

[page_break]

Capítulo 5
Política de seguridad

Ésta es la política que estoy escribiendo actualmente, está incompleta y no garantiza
absolutamente nada. El script será modificado para utilizar funciones por cada modelo en futuras
revisiones (ver TODO). Al igual que el resto del artículo no existe responsabilidad mía en caso
de errores, los cuáles están garantizados. Por lo tanto úsalo bajo tu responsabilidad.

Los comentarios están en inglés, la razón es aumentar la legibilidad del script (mejor todo
en inglés (FOR, IF...) que una mezcla de idiomas). La mayor parte de las reglas son
individuales en vez de en bucles, la razón es facilitar la modificación de éstas (muchos de los
DAC_READ_SEARCH pueden quitarse para hacer el DAC más estricto).

echo "setting up AUTH MODULE"

attr_set_fd AUTH FD auth_may_setuid 1 /bin/login

attr_set_fd AUTH FD auth_may_setuid 1 /bin/su

attr_set_fd AUTH FD auth_may_setuid 1 /usr/sbin/sshd

auth_set_cap FD add /usr/bin/man 13

auth_set_cap -g FD add /usr/bin/man 15

echo "setting up CAP MODULE"

#set binary (not links) maximum capabilities to 0

for FILE in /bin/* /sbin/* /usr/bin/* /usr/sbin/*

do

if [ ! -L "$FILE" ]

then for CAPABILITY in CHOWN DAC_OVERRIDE DAC_READ_SEARCH FOWNER
FSETID KILL SETGID SETUID SETPCAP LINUX_IMMUTABLE NET_BIND_SERVICE
NET_BROADCAST NET_ADMIN NET_RAW IPC_LOCK IPC_OWNER SYS_MODULE
SYS_RAWIO SYS_CHROOT SYS_PTRACE SYS_PACCT SYS_ADMIN SYS_BOOT
SYS_NICE SYS_RESOURCE SYS_TIME SYS_TTY_CONFIG MKNOD LEASE

do attr_set_file_dir -m CAP FILE $FILE max_caps $CAPABILITY

done

fi

done

#set binary maximum capabilities. BE CAREFULL SYS_MODULE SYS_ADMIN
SYS_RAWIO AND SYS_PTRACE are considered dangerous CAUTION WITH THEM.

#/bin

attr_set_file_dir -a CAP FILE /bin/login max_caps FOWNER CHOWN SETUID
SETGID

attr_set_file_dir -a CAP FILE /bin/chroot max_caps SYS_CHROOT

attr_set_file_dir -a CAP FILE /bin/mount max_caps SYS_ADMIN DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /bin/netstat max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/nice max_caps SYS_NICE

attr_set_file_dir -a CAP FILE /bin/passwd max_caps CHOWN

attr_set_file_dir -a CAP FILE /bin/killall max_caps KILL SYS_PTRACE

attr_set_file_dir -a CAP FILE /bin/ping max_caps NET_RAW

attr_set_file_dir -a CAP FILE /bin/su max_caps SETGID SETUID

attr_set_file_dir -a CAP FILE /bin/umount max_caps SYS_ADMIN DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /bin/chattr max_caps LINUX_IMMUTABLE FOWNER
DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/chmod max_caps FOWNER DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/chgrp max_caps CHOWN DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/cat max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/cp max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/dd max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/ls max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/dir max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/vdir max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/chown max_caps DAC_READ_SEARCH CHOWN

attr_set_file_dir -a CAP FILE /bin/kill max_caps KILL

attr_set_file_dir -a CAP FILE /bin/mknod max_caps MKNOD

attr_set_file_dir -a CAP FILE /bin/hostname max_caps SYS_ADMIN

attr_set_file_dir -a CAP FILE /bin/gawk-3.1.5 max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/grep max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/rm max_caps DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /bin/rmdir max_caps DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /bin/stat max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/zless max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/zmore max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/bzmore max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/bzdiff max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/bzgrep max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/bzip2 max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/bzip2recover max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/cksum max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/comm max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/cpio max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/du max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/gzip max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/gzexe max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/head max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/install max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/link max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/ln max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/lsattr max_caps DAC_READ_SEARCH

#attr_set_file_dir -a CAP FILE /bin/lsmod max_caps SYS_MODULE

attr_set_file_dir -a CAP FILE /bin/mkdir max_caps DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /bin/more max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/mv max_caps DAC_READ_SEARCH #DAC_OVERRIDE
to directories not owned by root

attr_set_file_dir -a CAP FILE /bin/nano max_caps DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /bin/readlink max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/ed max_caps DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /bin/sed max_caps DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /bin/sort max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/split max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/stty max_caps DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /bin/tar max_caps DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /bin/tee max_caps DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /bin/touch max_caps DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /bin/uniq max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /bin/unlink max_caps DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /bin/wc max_caps DAC_READ_SEARCH

#/sbin

attr_set_file_dir -a CAP FILE /sbin/arp max_caps NET_ADMIN

attr_set_file_dir -a CAP FILE /sbin/arping max_caps NET_RAW

attr_set_file_dir -a CAP FILE /sbin/badblocks max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /sbin/blockdev max_caps DAC_READ_SEARCH

attr_set_file_dir -a CAP FILE /sbin/losetup max_caps SYS_ADMIN IPC_LOCK

attr_set_file_dir -a CAP FILE /sbin/ctrlaltdel max_caps SYS_BOOT

attr_set_file_dir -a CAP FILE /sbin/lilo max_caps SYS_RAWIO

attr_set_file_dir -a CAP FILE /sbin/hdparm max_caps SYS_ADMIN SYS_RAWIO

attr_set_file_dir -a CAP FILE /sbin/hwclock max_caps SYS_RAWIO

attr_set_file_dir -a CAP FILE /sbin/ifconfig max_caps NET_ADMIN

#attr_set_file_dir -a CAP FILE /sbin/insmod max_caps SYS_MODULE

attr_set_file_dir -a CAP FILE /sbin/mii-tool max_caps NET_ADMIN

attr_set_file_dir -a CAP FILE /sbin/swapon max_caps SYS_ADMIN

attr_set_file_dir -a CAP FILE /sbin/pivot_root max_caps SYS_ADMIN

#attr_set_file_dir -a CAP FILE /sbin/rmmod max_caps SYS_MODULE

attr_set_file_dir -a CAP FILE /sbin/route max_caps NET_ADMIN

attr_set_file_dir -a CAP FILE /sbin/agetty max_caps DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /sbin/shutdown max_caps SYS_BOOT

attr_set_file_dir -a CAP FILE /sbin/halt max_caps SYS_BOOT

#/usr/bin

attr_set_file_dir -a CAP FILE /usr/bin/Xorg max_caps SYS_RAWIO SYS_TTY_CONFIG

#/usr/sbin/

attr_set_file_dir -a CAP FILE /usr/sbin/sshd max_caps NET_BIND_SERVICE CHOWN
SETGID SETUID SYS_CHROOT

attr_set_file_dir -a CAP FILE /usr/sbin/dsniff max_caps NET_RAW

attr_set_file_dir -a CAP FILE /usr/sbin/tcpdump max_caps NET_RAW

attr_set_file_dir -a CAP FILE /usr/sbin/useradd max_caps DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /usr/sbin/userdel max_caps DAC_OVERRIDE

attr_set_file_dir -a CAP FILE /usr/sbin/syslog-ng max_caps SYS_ADMIN

echo "setting up FF MODULE"

attr_set_file_dir -a FF DIR "/boot" ff_flags 132 #search_only and inheritance

attr_set_file_dir -a FF DIR "/usr/src" ff_flags 132

attr_set_file_dir -a FF DIR "/var/log" ff_flags 128 #write_only and inheritance

attr_set_file_dir -a FF DIR "/tmp" ff_flags 160 #no-execute and inheritance

attr_set_file_dir -a FF DIR "/home" ff_flags 160

attr_set_file_dir -a FF DIR "/var/tmp" ff_flags 160

#set binary (not links) File Flags to read_only and search_only

for FILE in /bin/* /sbin/* /usr/bin/* /usr/sbin/*

do

if [ ! -L "$FILE" ]

then attr_set_file_dir -a FF FILE $FILE ff_flags 129

fi

done

#set dirs search_only

for DIR in /bin /sbin /usr/bin /usr/sbin

do

attr_set_file_dir -a FF DIR $DIR ff_flags 132

done

#set libs read-only

for FILE in /lib/* /usr/lib/*

do

if [ ! -d "$FILE" ] && [ ! -L "$FILE" ]

then

attr_set_file_dir -a FF FILE $FILE ff_flags 129

else

if [ -d "$FILE" ]#to fix

then

attr_set_file_dir -a FF DIR $FILE ff_flags 129

fi

fi

done

#set libs dir read_only

for DIR in /lib /usr/lib

do

attr_set_file_dir -a FF DIR $DIR ff_flags 129

done

echo "setting up RC Module"

rc_set_item ROLE 4 name "LOG_ADMIN" #create rol LOG_ADMIN with id number
4

rc_set_item TYPE 4 type_fd_name "LOGS" #create type LOGS

attr_set_file_dir DIR /var/log rc_type_fd LOGS #/var/log assigned to type LOGS

rc_set_item -a ROLE 4 type_comp_fd LOGS READ

#X-window

rc_set_item ROLE 5 name "X-WINDOW"

attr_set_file_dir FILE /usr/bin/Xorg rc_force_role 5

rc_set_item -a ROLE 5 type_comp_scd 11 GET_STATUS_DATA #to kmem

rc_set_item -a ROLE 5 type_comp_fd General_FD SEARCH READ_OPEN
GET_STATUS_DATA READ MAP_EXEC CREATE WRITE_OPEN DELETE
MODIFY_PERMISSIONS_DATA LINK_HARD EXECUTE

rc_set_item -a ROLE 5 type_comp_dev General_DEV READ_OPEN READ WRITE
WRITE_OPEN IOCTL READ_WRITE_OPEN MODIFY_PERMISSIONS_DATA
GET_PERMISSIONS_DATA

rc_set_item -a ROLE 5 type_comp_netobj General_NETOBJ CREATE BIND LISTEN
WRITE ACCEPT CONNECT

rc_set_item -a ROLE 5 type_comp_process General_PROCESS SEND_SIGNAL
MODIFY_SYSTEM_DATA CREATE

rc_set_item -a ROLE 5 type_comp_scd 4 MODIFY_PERMISSIONS_DATA

rc_set_item -a ROLE 5 type_comp_ipc General_IPC CREATE READ_WRITE_OPEN
DELETE READ WRITE

rc_set_item ROLE 6 name "KERNEL_MANAGER"

rc_set_item TYPE 5 type_fd_name "BASE_LIBS"

rc_set_item TYPE 6 type_fd_name "GENERIC_LIBS"

rc_set_item TYPE 7 type_fd_name "KERNEL_OBJECT"

rc_set_item ROLE 7 name "UPNETUSER" #unpriviledge network daemon users

rc_set_item ROLE 8 name "BACKUP_ADMIN"

rc_set_item TYPE 8 type_fd_name "BASIC_EXEC" #Basic executables

rc_set_item TYPE 9 type_fd_name "ADMIN_EXEC" #Super user binaries

rc_set_item TYPE 10 type_fd_name "DEVEL_EXEC" #Compiler like binaries

#rc_set_item ROLE 9 name "PNETUSERXX" #for each priviledge service substitute XX by
the port name and assign an unique role ID

rc_set_item TYPE 11 type_fd_name "SECRET_DATA"

rc_set_item TYPE 12 type_fd_name "TOPSECRET_DATA"

Capítulo 6
ToDo

Para la versión 0.2 de la guía:

• Completar la política de RC. Sólo están las definiciones de los roles y los tipos. El
  rol forzado X-window no funciona todavía. Solucionarlo.
• Completar la política AUTH.
• Reparar la política FF.
• Añadir sección de registro.
• Corregir errores

Para la versión 0.3 de la guía:

• Añadir el módulo UM a la lista de módulos descritos
• Añadir la política del módulo RES
• Corregir errores

Para la versión 0.4 de la guía:

• Añadir el módulo DAZ a la lista de módulos descritos
• Añadir la “política” del módulo UM
• Corregir errores

Para la versión 0.5 de la guía:

• Añadir el Privacy Model (PM) a la guía
• Corregir errores

Para la versión 0.6 de la guía:

• Añadir política de ejemplo del PM
• Completar otras políticas.
• Corregir errores

Para la versión 0.7 de la guía:

• Añadir política MAC
• Corregir errores

Para la versión 0.8 de la guía:

• Corregir errores

Para la versión 0.9 de la guía:

• Reestructuración del artículo
• Corregir errores y lanzar la versión estable.

Bibliografía