Políticas de seguridad centralizadas para máquinas virtuales

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE CAMPUS ESTADO DE MÉXICO

POLÍTICAS DE SEGURIDAD CENTRALIZADAS PARA MÁQUINAS VIRTUALES

Asesor:

TESIS QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS DE LA COMPUTACION

PRESENTA

MANUEL ANTONIO GARCÍA CHANG

Dr. Roberto Gómez Cárdenas

Comité de Tesis: Dr. Eduardo de Jesús García García Dr. Felipe Rolando Menchaca García

Jurado: Dr. Eduardo de Jesús García García, Dr. Felipe Rolando Menchaca García, Dr. Roberto Gómez Cárdenas,

Presidente Secretario Vocal

Atizapán de Zaragoza, Estado de México. Noviembre de 2010.

Resumen

El Control de Acceso Obligado (CAO) es un método efectivo para proteger que los sistemas de computo sean mal utilizados. Debido a su complejidad, CAO no es utilizado ampliamente. La arquitectura actual de las máquinas virtuales no está diseñada para soportar CAO's de una manera global.

Mediante la arquitectura Políticas de Seguridad Centralizadas para Máquinas Virtuales (PSCMV) se centralizan las políticas CAO, de tal manera que toda la administración de las políticas pueda ser realizada desde una máquina central.

Abstract

Mandatory Access Control (MAC) is an effective method to protect computer systems from being misused. MAC is not widely used because of its complexity. Toe current architecture of virtual machines is not designed to support MAC in a site wide manner.

Centralized Security Policy for Virtual Machines (CSPVM) centralizes MAC policies, so that all policy managemente can easily be done from a central machine.

4

Contenido

1. INTRODUCCIÓN .............................. ..... ............................. ......................................................... _. ........... 12 2. LOS AMBIENTES VIRTUALES ............................................................................................................. 14

2.1 VIRTUALIZACIÓN ......................................................................................................................................... 14 2.2 NIVELES DE ABSTRACCIÓN ........................................................... ...................... ....... ................. ......... ..... 15 2.3 ESTRATEGÍAS DE VIRTUALIZACIÓN ............ .......... ................................................................................. 16 2.4 PLATAFORMAS DE VlRTUALIZACIÓN .................................................................................................... 17

3. SEGURIDAD EN AMBIENTES VlRTUALES ....................................................................................... 23 3.1 POLÍTICAS DE SEGURIDAD ........................................................................................................................ 23 3.2 TRABAJOS RELACIONADOS EN CUANTO A SEGURIDAD OBLIGATORIA EN EQUIPOS AISLADOS .............................................................................................................................................................. 25 3.3 TRABAJOS RELACIONADOS EN AMBIENTES VIRTUALES ................................................................. 28 3.4 SOLUCIÓN PROPUESTA ........................................................................................... .................................... 30 3.5 COMPARACION CON OTRAS PROPUESTAS ...................................... ...................................................... 31

4. DISEÑO DE LA ARQUITECTURA PSCMV ......................................................................................... 33 4.1 SERVICIO DE PLANIFICACIÓN ................................................................................................................. .33 4.2 SERVICIO STP .......................................... ............ ................. ................. ......................................... ..... .......... .34 4.3 SERVICIO SOP ................................................................................................................................................ 35 4.4 REPOSITORIO DE POLITICAS CA0 ............................................................................................................ 38 4.5 SERVICIO DE ADMINISTRACIÓN DEL REPOSITORI0 .......................................................................... 39 4.6 CANAL DE ALTA VELOCIDAD ......................................................... ............... ....... ........................ ........... .41 4.7 PROTOCOLO DE COMUNICACIÓN ........................................................................................................... .41

4.7.1 FUNCIONES UTILIZADAS POR EL HUÉSPED VIRTUAL.. ............................................................ .42 4.7.2 FUNCIONES UTILIZADAS POR EL NODO MAESTR0 ................................................................... .43

4.8 POLÍTICAS CAO EN LOS HUÉSPEDES VIRTUALES ............................................................................... 44 4.8.1 TRANSICIÓN DEL DOMINIO DE TOMOY0 ...................................................................................... 44 4.8.2 POLÍTICAS CAO SOPORTADAS EN LOS HUÉSPEDES VIRTUALES .......................................... .46 4.8.3 EXCEPCIONES CAO SOPORTADAS EN LOS HUÉSPEDES VIRTUALES .................................... .47

5. IMPLEMENTACIÓN DE LA ARQUITECTURA ...................................................................... ............ .48 5.1 CONSTANTES Y VARIABLES GLOBALES ................................................................................................ .49 5.2 MÉTODOS DE INICIALIZAClóN .............. ~ ................................................................................................... 51

5.2.1 MÉTODO protlnitializer() ........................................................................................................................ 51 5.2.2 MÉTODO windowLoader() ..................................................................................................................... 53 5.2.3 MÉTODO readDbParams() .......... .. ....................................................................... .. ............... .. ... ............. 54

5.3 SERVICIO DE PLANIFICAClóN ....................................................................... · ................. ........................... 55 5.3.1 MÉTODO activeServers() ........................................................................................................... ............. 56 5.3.2 MÉTODO updateActiveServers() ............................................................................................................ 57 5.3.3 MÉTODO bool cronMatcher(int pHour, int pMin) .................................................................................. 57 5.3.4 CICLO INFINITO DE EJECUCIÓN ....................................................................................................... 59

5.4 SERVICIO STP ................................................................................................................................................. 60 5.4.1 a) CREAR SOCKET EN EL HUÉSPED VIRTUAL ADMINISTRATIVO (STP) ................................ 60 5.4.2 b) CONECTAR SOCKET DEL STP AL HUÉSPED VIRTUAL.. ......................................................... 60 5.4.3 e) CONSULTA DEL REPOSITORIO CAO PARA LA OBTENCION DE POLÍTICAS ....................... 61 5.4.4 d) MANEJO DEL PROTOCOLO A NIVEL STP ........................................................................ .... ....... 6I 5.4.5 d.l) INICIALIZACióN DE VARIABLES PARA EL MANEJO DEL PROTOCOL0 .......................... 61 5.4.6 d.2) MANEJO DEL PROTOCOLO A NIVEL STP ............................. , .................................................. 62

5.5 SERVICIO SOP ................................................................................................................................................ 67 5.5.I a) CREAR SOCKET EN EL HUÉSPED VIRTUAL (SOP) .................................................................... 67 5.5.2 b) PROCESAR PETICIONES DEL SERVICIO STP (CLIENTE) ......................................................... 68 5.5.3 e) MANEJO DEL PROTOCOLO A NIVEL SOP ................................................................................... 69

5.6 REPOSITORIO DE POLITICAS CA0 ............................................................................................................ 72

5

5.6.1 a) CREACIÓN DEL OBJETO servers .............................................. ............ ........................................... 72 5.6.2 b) CREACIÓN DEL OBJETO kemels .................................................................................................... 73 5.6.3 e) CREACIÓN DEL OBJETO kemel_policies ........................................................................................ 73 5.6.4 d) CREACIÓN DEL OBJETO server_policies ....................................................................................... 75 5.6.5 e) CREACIÓN DEL OBJETO windows ................................................................ ................. ..... ............ 76 5.6.6 d) CREACIÓN DEL OBJETO parameters .............................................................................................. 77

5.7 CANAL DE ALTA VELOCIDAD ................................................................................................................... 78 5.7.1 a) MÉTODO getSocketHandle() .............................................................................................................. 78 5.7.2 b) MÉTODO printSocketlnfo() ....................................................... ............................................. ............ 79 5.7.3 e) MÉTODO bindToAnyPort() ............................................................. ........................ ........................... 79 5.7.4 d) MÉTODO bindToPort() .............................................................. : ........................................................ 80 5.7.5 e) MÉTODO receiveData() ...................................................................................................................... 81 5.7.6 t) MÉTODO sendData() ........................................................................................................................... 81

5.8 PROTOCOLO DE COMUNICACIÓN .......................................................................................... .................. 82 5.9 POLÍTICAS CAO EN LOS HUÉSPEDES VIRTUALES ............................................................................... 83

5.9.1 a) COMANDO sudo cat /tmp/file.txt » /etc/tomoyo/domain_policy.conf ............................................ 83 5.9.2 b) COMANDO sudo tomoyo-loadpolicy af ............................................................................................. 83 5.9.3 e) COMANDO sudo tomoyo-savepolicy ........................................................ ................. ........................ 84

6. PRUEBAS ................................................................................................................................................. 85 6.1 CARACTERf STICAS DE LOS NODOS UTILIZADOS DURANTE LA PRUEBA. .................................... 85

6.1.1 NODO MAESTR0 ................................................................................................................................... 85 6.1.2 HUÉSPEDES VIRTUALES .................................................................................................................... 85 6.1.3 NODO FISICO (PLATAFORMA DE VIRTUALIZACIÓN) ........ ..... ..................................... ............... 86

6.2 PREPARACION DE LOS NODOS ................................................................................................................. 86 6.2.1 NODO MAESTRO ................................................................................................................................... 86 6.2.2 HUESPEDES VIRTUALES .................................................................................................................... 86

6.3 INICIO DE LOS SERVICIOS ........................ .................................................................................................. 87 6.3.1 INICIO DEL SERVICIO SOP ............................................................................................ ..................... 87 6.3.2 INICIO DEL SERVICIO STP .................................................................................................................. 87

6.4 INTERCAMBIO DE DATOS ENTRE LOS SERVICIOS .............................................................................. 88 6.4.1 SERVICIO STP ............................................................................................................................... : ........ 88 6.4.2 SERVICIO SOP ........................................... .......... ........................ ................... ............... ......................... 92

6.5 APLICACION DE POLITICAS CA0 .................................................................................. ........................... 95 6.5.1 SERVICIO SOP ........................................................................................................................................ 95

7. CONCLUSIONES ..................................................................................................................................... 96 8. REFERENCIAS .................................. ....... ............ .............................................. ....... .............................. 97

6

Lista de Figuras

Figura 1. Servicio de Planificación ................................................................................................................ .34 Figura 2. Operación de transmisión de pollticas CA0 ................................................................................... 35 Figura 3. Operación de validación del master node ....................................................................................... 36 Figura 4. Operación de recepción de políticas CA0 ........................................................................ , ............. 37 Figura 5. Operación de aplicación local de políticas CA0 ............................................................................ 38 Figura 6. Objetos del repositorio de políticas CAO ...................................................................................... .40 Figura 7. Stream Socket Orientado a Conexión ............................................................................................ .42

7

Lista de Tablas

Tabla 1. Funcionalidad del Servicio de Administración del Repositorio por tipo de operación ... .... ... ......... .41 Tabla 2. Transición del dominio de TOMOYO, parte l... .... .......... ..... ....... ........ .... .. ... .. .... ......... ...... .......... ... .45 Tabla 3. Transición del dominio de TOMOYO, parte 2 .......... ...... .. ... .......... .... ...... ... ...... ................ ..... ........ .. 46 Tabla 4. Directivas de configuración del archivo domain_policy (TOMOY0) .......... ........ .... ...... ................. 46 Tabla 5. Directivas de configuración del archivo domain_policy (TOMOY0) .................. .. ..... ............. ..... . .47 Tabla 6. Directivas de configuración del archivo exception_policy (TOMOY0) .... ...... ................. .. ... .. .... .. .47 Tabla 7. Parámetros leídos de la Base de Datos en tiempo de artanque ...... .. ..... ............ ... ... .. ... .... .... .. ... ....... 54 Tabla 8. Protocolo de comunicación entre el servicio STP y el servicio SOP ............. .. .... ..... ... .................... 82

8

Lista de Código Fuente

Código 1. Constantes ..................................................................................................................................... .49 Código 2. Variables globales, parte l ............................................................................................................. 50 Código 3 .Variables globales, parte 2 ................................................................... ................. ......................... 5 I Código 4. Inicialización del protocolo, parte l ............................................................................................... 52 Código 5. Método windowLoader() ............................................................................................................... 53 Código 6. Método readDbParams(), parte 1 ................................................................................................... 54 Código 7. Método readDbParams(), parte 2 .................................................................................................. .55 Código 8. Servicio de Planificación ....................................................... ..... ..... .............................................. 56 Código 9. Método activeServers() .................................................................................................................. 56 Código 1 O. Método updateActiveServers() .................................................................................................... 57 Código 11. Método cronMatcher() ................................................................................................................. 58 Código 12. Ciclo infinito de ejecución ............................................................................ ............... ................ 59 Código 13. Bloque para crear socket en el huésped virtual administrativo .................................................... 60 Código 14. Conectar socket del STP al huésped virtual... .............................................................................. 61 Código 15. Consulta del repositorio CAO para la obtención de políticas ...................................................... 61 Código 16. Inicialización de variables para el manejo del protocolo ............................................................. 62 Código 17 .Manejo del protocolo a nivel STP, parte l... ............................. ............ .. ..... ............................... 63 Código 18 .Manejo del protocolo a nivel STP, parte 2 .................................................................................. 64 Código 19 .Manejo del protocolo a nivel STP, parte 3 .................................................................................. 65 Código 20 .Método challengeProcessor() ....................................................................................................... 66 Código 21 . Crear socket en el huésped virtual (SOP) ................................................................................... 67 Código 22 .Procesar peticiones del servicio STP (cliente) ............................................................................. 68 Código 23.Manejo del protocolo a nivel SOP, parte 1 ................................................................................... 69 Código 24. Manejo del protocolo a nivel SOP, parte 2 .................................................................................. 70 Código 25. Manejo del protocolo a nivel SOP, parte 3 .................................................................................. 71 Código 26 .Método getSocketHandle() .......................................................................................................... 78 Código 27 .Método printSocketlnfo() .................................................................................... ........................ 79 Código 28 .Método bindToAnyPort() ............................................................................................................ 80 Código 29 .Método bintToPort() .................................................................................................................... 80 Código 30 .Método receiveData(), parte l ..................................................................................................... 81 Código 31 .Método sendData() ....................................................................................................................... 82 Código 32. Generación de llaves PEM en el nodo maestro ........................................................................... 86 Código 33. Inicio del servicio S0 .............................................................................................. ..................... 87 Código 34. Inicio del servicio STP ................................................................................................................. 88 Código 35. Intercambio de mensajes, servicio STP. Parte l... ....................................................................... 88 Código 36. Intercambio de mensajes, servicio STP. Parte 2 .......................................................................... 89 Código 37. Intercambio de mensajes, servicio STP. Parte 3 ......................... ............................. .. .................. 90 Código 38. Intercambio de mensajes, servicio STP. Parte 4 .......................................................................... 91 Código 39. Intercambio de mensajes, servicio STP. Parte 5 .......................................................................... 92 Código 40. Intercambio de mensajes, servicio SOP. Parte l.. ........................................................................ 92 Código 41. Intercambio de mensajes, servicio SOP. Parte 2 .......................................................................... 93 Código 42. Intercambio de mensajes, servicio SOP. Parte 3 .......................................................................... 94 Código 43. Aplicación de políticas CAO por el servicio SOP ....................................................................... 95

9

Lista de Scripts

Script 1. Creación del objeto servers ........... .... ............ ........ ... .. .. ...... .. .. ......... ...... ..... .... .................................. 72 Script 2. Creación del objeto kemels .... ...... .... ... ....... .. ... ......... .... ..... ..... .......... .... ............. ...... ... ............. ......... 73 Script 3 .Creación del objeto de base de datos kernel_policies, parte J... .................... .... ..... .. .... .................... 73 Script 4. Creación del objeto de base de datos kemel_policies, parte 2 ................ .. ...... ........ .. ....................... 74 Script 5. Creación del objeto de base de datos kemel_policies, parte 3 .................... .. ..... .... ........ .... .............. 75 Script 6. Creación del objeto de base de datos server_policies, parte l... ........................... ........................... 75 Script 7. Creación del objeto de base de datos server_policies, parte 2 ..................... ..... ..... .... ...................... 76 Script 8. Creación del objeto de base de datos windows, parte l... ....................................... ......................... 76 Script 9. Creación del objeto de base de datos windows, parte 2 ............................ ............ ........................... 77 Script 10. Creación del objeto de base de datos parameters, parte J... ........ .... ... ... ............ ... ....... ............ .... ... 77 Script 11. Creación del objeto de base de datos parameters, parte 2 ..... ..... ... ...... ......... .. ................................ 78

10

ABREVIATURAS Y SIMBOLOS

-------------------·------------- -------, --- - ---- ------·---·-- ·-- - - ----·- ---·-·-·---------------------------------------- -- - -- ------·- -- . ~

li __ ----~~~!·-~~~---------1--------------- __________ Desci¿_pción_________________ _ -1

CAO · Control de Acceso Obligatorio ¡ -- - --- --- ------------------ ------------l-------------------------- --- ------------------------------------ - --------1

¡ CAOV I Control de Acceso Obligatorio para Máquinas Virtuales ! 1- ·----- - --- ··- ·--------------·-------t---·--------- -----·-·--·- ---····---- ·-------- ·- --------··· -----·------- - ·-----------------·----------------------~

I MAC : Mandato[)' Access Control j

¡-MV- ------ -- i Máquina Vi~I- - -_ - -_ -- _ --- ---~=:--=-~=-~~-::::~=-====-~--=--- -; ¡:; ==---== i ;:.;.:;;. ~---=-=--------------------=-~:~=~---=-~·-:---~-.--:~j ¡ PSCMV ! Políticas de Seguridad Centralizadas para Máquinas Virtuales

1,

i -------------t= -------------------------------------- ---- -- -----------ISO , Sistema Operativo l. ________________ l_ _____________ ---------------------------------------------------------

11

l. INTRODUCCIÓN Recientemente, la virtualización ha surgido como uno de los tópicos mas candentes en el área de sistemas computacionales, acercando la atención de los sectores industriales y de la academia. Hay varios sistemas de virtualización disponibles, desde soluciones comerciales tal como VMWare o Microsoft Virtual PC a soluciones libres como UML (User Mode Linux), Open VZ, Vserver, KVM (Kemel-based Virtual Machine) y Xen.

Para tratar los problemas de Control de Acceso Discrecional (CAD), es necesario eliminarlos y emplear CAO. Con CAO un usuario malicioso (o código malicioso) no podrá abusar de recursos para un propósito distinto al que especifica el sistema. Dado que el Control de Acceso Obligatorio (CAO) solamente puede ser cambiado por el administrador del sistema, el código dañino no podrá modificar la política sin la aprobación del sistema. CAO puede detener o mitigar de manera eficiente daños a la seguridad; sin embargo, dada la complejidad de implementación muchos administradores escogen deshabilitar CAO y regresar a CAD.

Los sistemas con máquinas virtuales enfrentan un problema mayor cuando se desean implementar Controles de Acceso Obligatorios (CAO) : los esquemas actuales no cubren CAO en el ambiente de las Máquinas Virtuales (MV). Una sistema con múltiples máquinas virtuales necesita contar con múltiples políticas de seguridad, y cada una de estas políticas deben ser administradas de manera separada en cada huésped virtual. Cuando el administrador necesita actualizar las políticas de seguridad de un huésped especificado, debe firmarse en ese huésped y realizar el trabajo. Cuando un administrador necesita actualizar las políticas de seguridad para un servidor en particular, debe firmarse a ese equipo para llevar a cabo la tarea. Como resultado, el administrar múltiples máquinas con cientos o miles de máquinas virtuales es una actividad complicada que consume mucho tiempo, especialmente si cada máquina virtual emplea diferentes políticas. Claramente, se necesitan métodos más eficientes y flexibles para resolver este problema.

12

Está tesis propone el diseño de una arquitectura para la centralización de políticas CAO en ambientes virtuales llamada Políticas de Seguridad Centralizadas para Máquinas Virtuales (PSCMV); mediante la implementación de Controles de Acceso Obligatorio en equipos virtuales (CAOV); de tal forma que la administración de políticas CAO se realice de manera sencilla y flexible desde un equipo central.

En lugar de tener las políticas de seguridad dentro de cada máquina virtual, PSCMV mueve las políticas de seguridad fuera de las máquinas virtuales, y las pone en una máquina central. Esta estrategia permite a los administradores administrar las políticas de seguridad de todos las máquinas virtuales desde una máquina virtual administrativa. Como resultado, el actualizar el CAO de las máquinas virtuales resulta ser más fácil, dado que puede ser realizado desde un lugar central.

El resto del documento se organiza como se describe a continuación. El capítulo 2, Ambientes de Virtualización hace una revisión de los niveles de abstracción, estrategias de virtualización y al final presenta las plataformas de virtualización disponibles.

En el capítulo 3, Seguridad en Ambientes Virtuales presenta el estado actual de la cuestión, haciendo una revisión de las arquitecturas de seguridad propuestas para ambientes virtuales. Se presentan los trabajos relacionados en cuanto a seguridad obligatoria en equipos aislados así como en ambientes virtuales. Al final de este capítulo se describe la solución propuesta.

El capítulo 4, Diseño de la Arquitectura PSCMV, describe la arquitectura llamada Políticas de Seguridad Centralizadas para Máquinas Virtuales VMWare.

En el capítulo 5, Implementación de la Arquitectura PSCMV se detallan todos los aspectos técnicos requeridos para la implementación de la arquitectura.

Las Pruebas a la arquitectura son presentadas en el capítulo 6, tres máquinas virtuales son utilizadas para la realización de las pruebas; una máquina virtual es utilizada como nodo maestro y dos son utilizadas como huéspedes virtuales.

Finalmente en el capítulo 7 se presentan las conclusiones.

13

2. LOS AMBIENTES VIRTUALES

2.1 VIRTUALIZACIÓN

Virtualización es una tecnología que combina o divide los recursos de computo para presentar uno o varios sistemas operativos empleando metodologías como particionamiento o agregación a nivel hardware y software , simulación parcial o completa de una máquina, emulación, tiempo compartido y muchas otras [22].

La virtualización y el aislamiento permite muchos ambientes virtuales dentro del mismo kernel. Mediante el subsistema de administración de recursos se limitan los recursos tal como el CPU, RAM y espacio en disco por ambiente virtual.

Virtualización [ 18] se refiere a las tecnologías diseñadas para proveer una capa de abstracción entre el hardware de las computadoras y el software que se está ejecutando en ellas. Al proveer una vista lógica de los recursos de computo, en vez de una vista física, las soluciones de virtualización hacen posible el realizar cosas muy útiles: para hacer creer al sistema operativo que un grupo de servidores es un conjunto de recursos de computo. Lo cual permite la ejecución de múltiples sistemas operativos en una misma máquina. La virtualización tiene sus raíces en la división de un servidor físico en múltiples servidores lógicos.

La virtualización está cambiando la forma en la que los recursos son desplegados y administrados, simplificando y acelerando las respuesta de Tecnología de la Información (TI) a los ambientes de negocios [ 19]. Se reducen los costos administrativos de TI al ejecutar múltiples aplicaciones y sistemas operativos de manera independiente en un solo servidor fisico.

La virtualización no solo brinda la habilidad de administrar el hardware mas eficientemente, pero también permite tratar el software que se ejecuta de manera diferente. A vanees recientes en el hardware y software han contribuido a mejorar el rendimiento asociado con las máquinas virtuales. En el futuro cercano todas las nuevas máquinas tendrán capacidades embebidas de virtualización en su firmware. Actualmente la sobrecarga en los equipos virtuales va desde un pequeño porcentaje hasta un 20%, un valor que depende de varios factores, incluyendo como el hypervisor es implementado y si el sistema operativo que aloja al equipo virtual sabe que está siendo virtualizado [17].

14

En adición al aspecto del rendimiento, queda todavía el aspecto de administración en los centros de datos y en cualquier otro lado. Para la siguiente generación de máquinas virtuales, cada gran compañía de software estará trabajando en herramientas de administración comprensiva. El objetivo, es lidiar con un nwnero masivo de máquínas virtuales y efectivamente tomar decisiones de optimización globales para miles de equipos virtuales corriendo en un centro de datos. Herramientas de administración sofisticadas serán esencial en el futuro cercano.

El significado original de una máquina virtual de sistema operativo, también conocida como máquina virtual de hardware, es que varios ambientes idénticos de ejecución son ejecutados en un equipo fisico. Uno de los usos mas populares de las máquinas virtuales es la de permitir que un usuario ejecuta múltiples sistemas operativos al mismo tiempo en un equipo fisico. Al software que proporciona esta habilidad frecuentemente se le refiere como hypervisor o monitor de la máquina virtual (MMV).

2.2 NIVELES DE ABSTRACCIÓN

Conceptualmente una máquina virtual representa un ambiente de operación para un conjunto de aplicaciones a nivel usuario, lo cual incluye librerías, interfaz de llamadas al sistema, configuraciones del sistema, procesos de tipo daemon y el estado del sistema de archivos. Hay varios niveles de abstracción en los ambientes de virtualización: a nivel conjunto de instrucciones (lnstruction set architecture - ISA), abstracción a nivel hardware (hardware abstraction /ayer -HAL), a nivel sistema operativo (SO), a nivel librerías o a nivel aplicación [22]. No importando el nivel de abstracción, se dividen los recursos de bajo nivel empleando alguna técnica novedosa para mapear hacia múltiples MVs de manera transparente.

La virtualización a nivel ISA trata sobre la emulación del conjunto de instrucciones. La emulación es la técnica de interpretar las instrucciones por software. Por ejemplo, un emulador x86 en un procesador Sparc puede ejecutar cualquier aplicación x86, dando la ilusión de que la aplicación se está ejecutando en un procesador x86. Para lograr esto, el emulador debe ser capaz de traducir el ISA del huésped (x86) al ISA del anfitrión (Sparc ).

La funcionalidad y nivel de abstracción de un nivel HAL reside entre una máquina física y un emulador. Una máquina virtual es un ambiente creado por un MMV, lo cual es el software de virtualización entre el hardware y el SO y da al SO una vista virtualizada de todo el hardware. Un MMV puede crear múltiples máquinas virtuales (MVs) en un solo equipo fisico. Mientras que un emulador proporciona una capa completa entre el sistema operativo o aplicaciones y el hardware. Una MMV administra una o más MVs en donde cada MV proporciona facilidades a un SO o aplicación para hacerle creer que se está ejecutando en un ambiente normal y directamente sobre el hardware.

La virtualización a nivel SO trabaja encima o como un módulo del SO para proveer una interfaz virtualizada de llamadas al sistema. Dado que la invocación de llamadas al sistema es la única fonna de comunicación entre el espacio del usuario y el espacio del kernel, debe ser posible para el software de virtualización controlar totalmente lo que pueden realizar los procesos del espacio del usuario al administrar esta interfaz.

15

La mayoría de las aplicaciones emplean los APis exportados por librerías a nivel usuario en vez de llamadas directas al sistema para la implementación de su lógica. Dado que la mayoría de los sistemas proveen APis bien documentados y formas bien definidas de engancharlos, tal interfaz resulta ser otro candidato para la virtualización. La virtualización a nivel interfaz de librería es posible al controlar la liga de comunicación entre las aplicaciones y el resto del sistema por medio de los ganchos (hooks) de los APis. Esto puede, a su vez, exponer una implementación diferente al mismo tiempo utilizando el mismo conjunto de APls y aún así tener un sistema en ejecución.

La virtualización a nivel aplicación es un poco diferente. No se trata solamente de insertar la capa de virtualización en medio; en vez de eso, se implementa una capa de virtualización que eventualmente creará una máquina virtual. La MV creada podría ser tan simple como un interprete de lenguaje o tan complejo como un NM (Java Virtual Machine).

Todas estas tecnologías de virtualización difieren significativamente en términos de rendimiento, flexibilidad, facilidad de uso, consumo de recursos y escalabilidad; de ahí, difieren en los escenarios de uso también.

2.3 ESTRA TEGÍAS DE VIRTUALIZACIÓN

En cuanto a las estrategias principales de virtualización que están en uso para ambientes productivos de computo, se encuentran:

l. Virtualización Completa. Llamada algunas veces emulación de hardware. En este caso un sistema operativo no modificado es ejecutado empleando un hypervisor para traducir/ejecutar instrucciones privilegiadas al vuelo. Debido a que el interceptar instrucciones privilegiadas puede llevar a penalizaciones de rendimiento, estrategias novedosas son utilizadas para agregar múltiples instrucciones y traducirlas de manera simultanea. Otras mejoras, tal como la traducción binaria, puede mejorar el rendimiento al reducir la necesidad de traducir estas instrucciones en el futuro.

2. Paravirtualización: Similar a la virtualización completa, la paravirtualización también emplea un hypervisor, y también emplea el termino máquina virtual para referirse a sus sistemas operativos virtualizados. Esto permite a las MVs coordinarse con el hypervisor, reduciendo el uso de instrucciones privilegiadas que son típicamente responsable de la mayoría de penalizaciones de rendimiento en la virtualización completa. Debido a la paravirtualización, los huéspedes existen como sist.emas operativos independientes. La administración de recursos existe en la forma de asignación de memoria, y asignación de CPU.La ventaja es de que las máquinas virtuales paravirtualizadas típicamente superan el rendimiento de las máquinas virtuales con virtualización completa. La desventaja, sin embargo, es la necesidad de modificar la máquina virtual/sistema operativo paravirtualizado para ser consciente del · hypervisor. Esto tiene implicaciones para sistemas operativos sin código fuente disponible.

16

3. Virtualización a nivel Sistema Operativo. A diferencia de la virtualización completa así como la paravirtualización, la virtualización a nivel sistema operativo no se basa en un hypervisor. En vez de eso, el sistema operativo es modificado para aislar de manera segura múltiples instancias de sistema operativo dentro de un solo equipo fisico. Las instancias huésped de los sistemas operativos se conocen frecuentemente como servidores privados virtuales (SPV). La ventaja de la virtualización a nivel sistema operativo es el rendimiento. La desventaja principal es de que todas las instancias de SPV comparten un solo kernel. Así, si el kernel falla o se compromete, todas las instancias SPV también se comprometerán. Sin embargo, el tener una sola instancia de kernel tiene la ventaja de que se consumen menos recursos debido a la sobrecarga del sistema operativo de múltiples kernels.

4. Virtualización Nativa: La virtualización nativa aprovecha el soporte a nivel hardware para la virtualización dentro del procesador mismo para apoyar en el esfuerzo de virtualización. Pennite la ejecución de múltiples sistemas operativos no· modificados. La virtualización nativa no emula un procesador.

2.4 PLATAFORMAS DE VIRTUALIZACIÓN

VMWare es actualmente el líder del mercado en cuanto tecnología de virtualización. VMWare Server incluye tanto Virtualización Completa como Virtualización Nativa, así como soporte limitado SMP. VMWare opera encima de los sistemas operativos Linux y Windows [23].

VMWare Server soporta tres tipos de conectividad: bridged networking, NAT networking y hostonly networking. Bridged networking permite que múltiples máquinas virtuales actúen como si fueran servidores distintos, en donde a cada máquina virtual se le asigna una dirección IP diferente. NAT networking permite a las máquinas virtuales comunicarse empleando la misma dirección IP. Host-only networking puede ser utilizado para permitir que las máquinas virtuales se comuniquen directamente con el servidor (que las aloja) sin la necesidad de una interfaz de red verdadera.

VMWare Server se instala y se ejecuta como una aplicación encima de un sistema operativo anfitrión Windows o Linux. Una capa delgada de virtualización divide al servidor físico de tal manera que múltiples máquinas virtuales puedan ser ejecutadas de manera simultanea en un mismo servidor. Los recursos de computo del servidor fisico son tratados como un conjunto de recursos uniforme que puede ser asignado a una máquina virtual de una manera controlada. VMWare server aisla cada máquina virtual de su anfitrión así como las otras máquinas virtuales, dejándola sin afectación en caso de que otra máquina virtual crashes. No hay fugas de datos entre las máquinas virtuales y las aplicaciones solamente se pueden comunicar a través de conexiones de red configuradas. VMWare Server encapsula un ambiente de máquinas virtuales como un conjunto de archivos, los cuales son fácil de respaldar, mover y copiar.

La versión 2 de VMWare Server soporta los siguientes sistemas operativos: Windows Server 2008, Windows Vista Business Edition y Ultimate Editionm Red Hat Enterprise Linux 5 y Ubuntu 8.0.4; incluyendo soporte en modo para-virtualizado en ciertas distribuciones de Linux [24].

17

La versión 2 de VMWare también tiene soporte a sistemas operativos de 64 bits: Utiliza sistemas operativos huésped de 64 bits en hardware de 64 bits para permitir soluciones de computo más escalables y con mejor rendimiento. En adición, VMWare Server 2 se ejecuta de manera nativa en sistemas operativos anfitrión Linux de 64 bits [24].

Xen es una capa delgada de software que es ejecutada encima del hardware. Xen expone la abstracción de una Máquina Virtual (MV) que es ligeramente diferente del hardware en el que se basa. Xen introduce una nueva arquitectura llamada xen, la cual es muy similar a la arquitectura x86. Las MVs que se ejecutan bajo Xen son modificadas (a nivel del núcleo) para poder trabajar con la arquitectura de xen. Con el núcleo de Xen, el impacto al rendimiento de los equipos virtuales es bajo: solamente alrededor del 3% en algunos experimentos publicados [14]. Todos los accesos de los máquinas virtuales al hardware y a los periféricos pasan a través de Xen, de tal forma que Xen puede vigilar de cerca a las MVs y controlar todas las actividades.

Xen fue desarrollada originalmente por investigadores de la Universidad de Cambridge, actualmente Xen está respaldado por varios jugadores de la industria tal como IBM, lntel, AMO, HP, Red Hat y Novell. La comunidad completa de Xen está trabajando para llevar el código al núcleo de Linux, de tal forma que este disponible para ser utilizado por todos los usuarios de Linux.

Xen es la implementación de paravirtualización más popular en uso en código abierto. El almacenamiento en Xen puede existir ya sea como un solo archivo, como particiones o volúmenes lógicos [23].

La creación de redes de Xen está completamente virtualizado. Una serie de dispositivos ethernet virtuales son creados en el sistema anfitrión, los cuales funcionan como puntos finales de interfaces de red en los anfitriones. Una vez que se instancia el huésped, uno de los dispositivos ethernet virtuales es empleado como el punto final (endpoint). El huésped ve los puntos finales como dispositivos ethernet entandar (e.g. "ethO"). A cada dispositivo ethernet virtual también se le asigna una dirección MAC. Briding es utilizado en el anfitrión para para permitir que todos los huéspedes aparezcan como servidores independientes [23].

A las máquinas virtuales, se les conoce como dominios en Xen, los cuales son construidos encima de hypervisor de Xen. Una MV especial, llamada DopiO (dominio O) es creada primero. Tiene la función de administrar a las otras máquinas virtuales (crear, destruir, migrar, almacenar, restaurar) y controla la asignación de dispositivos de Entrada/Salida a las MVs.

Xen ofrece dos recursos virtuales compartidos sobre lo cual se implementa todas las comunicaciones entre MVs: El canal de eventos y la memoria compartida. El canal de eventos permite a una MV definir una canal de sincronización punto a punto hacía otra MV. Mediante el concepto de memoria compartida se habilita que una máquina virtual conceda a otra acceder las páginas de memoria virtual de las cuales es dueño. Los canales de eventos son utilizados para sincronizar el acceso a la memoria compartida.

18

OpenVZ es la versión de código abierto de "Swsoft's Linux Virtuozzo product". Emplea virtualización a nivel sistema para lograr un rendimiento casi nativo para los sistemas operativos huéspedes. Open VZ agrega la siguiente funcionalidad: virtualización y aislamiento de los diferentes subsistemas, administración de recursos y checkpointing .Debido a su integración con el kernel de Linux, Open VZ es capaz de lograr un nivel de granularidad en el control de recursos que no pueden la virtualización completa ni la paravirtualización. Open VZ es capaz de limitar un huésped en particular en cuanto al tamaño del buffer de comunicación (e.g. los buffers de TCP de tipo send y receive) así como la memoria del kernel, páginas de memoria, y espacio en disco a nivel inode. Los ajustes solamente pueden ser realizados por el sistema anfitrión, lo que significa que un administrador de un sistema operativo huésped no podrá cambiar los limites de sus recursos [23].

Checkpointing es el proceso de "congelar" un ambiente virtual, guardar su estado completo a disco, con la habilidad de "descongelar" ese estado más adelante [25].

Open VZ virtualiza de manera completa sus subsistemas de red y permite a los usuarios escoger entre utilizar un dispositivo de red virtual o un dispositivo ethernet virtual. El dispositivo de red virtual por defecto es el más rápido, pero no permite a los administradores de los huéspedes manipular la configuración de red. El dispositivo ethernet de virtual es configurable por el administrador del huésped y actúa como un dispositivo ethernet estándar. Utilizando el dispositivo ethernet virtual, todos los huéspedes están aislados de manera segura ( en términos de trafico de red).

Microsoft Virtual PC, es un producto muy similar a lo que se ofrece en VMWare Workstation. Está basado en la arquitectura MMV (Monitor de Máquina Virtual) y permite que el usuario cree y configure uno o más máquinas virtuales. A parte de las características soportadas por VMW are, proporciona dos funcionalidades adicionales. Mantiene un disco de undo que permite al usuario deshacer algunas operaciones previas en el disco de una MV. Esto facilita la recuperación de datos de manera sencilla que puede ser de mucha utilidad en varias circunstancias. La otra funcionalidad es la de traducción binaria (binary translation), lo cual emplea para proporcionar máquinas x86 en máquinas basadas en Macintosh. ·

Linux, FreeBSD, OpenBSD, Solaris, etc no son soportados como sistemas operativos huésped en Microsoft Virtual PC. Las MVs de Microsoft Virtual PC no soportan dispositivos SCSI, a diferencia de VMWare Workstation, aunque algunos discos SCSI son reconocidos como IDEs por las MVs. No permite que los usuarios agreguen o actualicen el conjunto de hardware de una MV. Una vez configurada, no es posible cambiar los dispositivos de hardware que una MV posee. Linux u otros sistemas operativos exóticos no están disponibles como sistema operativo huésped [22].

User-mode Linux, o UML, es un proyecto de código abierto que permite a los usuarios ejecutar Linux encima de Linux. Básicamente, proporciona una máquina virtual en la que una versión de Linux se puede ejecutar tal como lo haria en una máquina física, y todo implementado a nivel usuario. Permite a los usuarios configurar recursos virtuales de hardware que estarán disponibles para el kernel de Linux de los huéspedes. Dado que todo está en ejecución a nivel usuario, se garantiza la seguridad. El soporte de hardware viene en la forma de dispositivos virtuales que hacen uso de recursos físicos. Entre los dispositivos soportados están, dispositivos de bloque,

19

consolas, lineas seriales, dispositivos de red, dispositivos SCSI, USB, Sonido, etc. EL UML ejecuta su propio planificador independiente del planificador del anfitrión, ejecuta su propio sistema de memoria virtual, y básicamente soporta cualquier cosa que no sea especifico de hardware. También soporta SMP y highmem. La implementación de manejador de consola virtual permite al usuario adjuntarlo a un número de interfaces disponible en el anfitrión: descriptores de archivo, ptys, ttys, dispositivos pts y xterms.

La implementación de UML involucra un puerto del kernel de Linux a la interfaz de llamadas al sistema de Linux en vez de una interfase de hardware. En este sentido, tanto la máquina virtual como el kernel de Linux del huésped están altamente acoplados. Estando en ejecución totalmente en el espacio del usuario, el desafio mayor es el de interceptar las llamadas al sistema en el kernel virtual, debido que naturalmente pasarían por el kernel real del anfitrión. Utilizando ptrace de Linux para rastrear las llamadas al sistema, se desvían las llamadas del sistema hechas por los procesos en ejecución dentro de la Máquina Virtual al kernel del espacio del usuario para ejecutarlos. Similarmente, se implementan trampas (traps) por medio de señales de Linux. El Kernel y los procesos dentro de la MV comparten el mismo espacio de direcciones; y los conflictos con la memoria de los procesos se evitan al poner el texto del kernel y los datos en áreas en donde no es probable que los procesos ocupen. Cada proceso en la máquina virtual obtiene su proceso en el kernel del anfitrión. Para que se pueda compartir los datos del kernel virtual entre todos los procesos dentro de la MV, su segmento de datos es copiado dentro de un archivo, y el archivos es mapeado como compartido a todos los procesos [22].

La tecnología de Linux-VServer es un concepto de particionamiento basado en Contextos de Seguridad, lo cual permite la creación de muchos Servidores Privados Virtuales (SPV) que se ejecutan de manera simultanea en un mismo servidor fisico a toda velocidad, compartiendo de manera eficiente recursos de hardware.

Un SPV provee un ambiente operativo casi idéntico tal como un servidor Linux convencional. Todos los servicios tales como ssh, mail, web y servidores de base de datos pueden ser iniciados en los SPVs, sin modificación, justo como en los servidores reales.

Cada SPV tiene su propia base de datos de cuentas de usuario, password de root y está aislado de los otros servidores virtuales, excepto del hecho de que comparten los mismos recursos de hardware.

Linux VServer es un jail mechanism que puede ser utilizado para dividir de manera segura los recursos en un sistema de computo (tal como el sistema de archivos, tiempo de CPU, direcciones de red y de memoria) de tal forma que los procesos no pueden montar un ataque de tipo DOS (Denial of service) fuera de su partición. [26].

A cada partición se le conoce como Contexto de Seguridad y el sistema virtualizado dentro de su servidor privado virtual. Una utileria parecida a chroot para descender a los contextos de seguridad es proporcionada. El arrancar un servidor privado virtual es tan simple como activar "init" en un nuevo contexto de seguridad; igualmente, el detener consiste en detener los procesos en ese contexto de seguridad. Los contextos por si mismo son lo suficiente robustos para arrancar muchas distribuciones de Linux sin modificar incluyendo Debian y Fedora [26]. $¡~-d S'y

(10.,..,-<;:, 1,\\'\ DEEJr¿,0 ~C~

~~~.20

'I ~~h~"i • .()~""O o 1..sr.~,j $¡ ~~Oo ~{ ~ :"__~,1.~'Y ...... ~

Ventajas de Linux-VServer [26]: • Los servidores virtuales comparten la misma interfaz de llamadas al sistema y por lo tanto

no tienen ninguna sobrecarga de emulación. • Los servidores virtuales no tienen que ser respaldados por imágenes opacas de disco,

pueden compartir un sistema de archivos común y conjuntos comunes de archivos. Esto lo hace más fácil para respaldar el sistema y para asignar espacio en disco entre los servidores virtuales.

• Los procesos dentro del servidor virtual se ejecutan como procesos regulares en el sistema anfitrión. Esto es eficiente en cuanto al uso de memoria y la E/S comparado contra la emulación completa del sistema, lo cual no podría regresar memoria no utilizada o compartir un cache de disco con el anfitrión y otros servidores virtuales.

• Los procesos dentro del servidor virtual están en un queue en el mismo planificador que el anfitrión, pennitiendo que los procesos huésped se ejecuten de manera simultanea en sistemas SMP.

• La parte de r~d se basa en aislamiento en vez de virtualización, por lo tanto no hay sobrecarga adicional para los paquetes.

• Solamente un kernel se tiene que revisar en cuanto a bugs de seguridad.

KVM es un hypervisor. Los desarrolladores de K VM, en vez de crear las porciones principales de un kernel de sistema operativo, tal como otros hypervisors lo han hecho, concibieron un método que tomo el kernel de Linux en un hypervisor. Esto fue logrado a través de un método poco intrusive al desarrollar KVM como un módulo del kernel. El integrar la funcionalidad del hypervisor dentro del kernel del Linux en el anfitrión como un modulo puede simplificar la administración y mejorar el rendimiento en ambientes virtualizados. Esto probablemente fue la razón principal para que los desarrolladores agregarán KVM al kernel de Linux [27].

Este enfoque tiene numerosas ventajas. Al agregar capacidades de virtualización a un kernel de Linux entandar, el ambiente virtualizado se puede beneficiar de todo el trabajo en marcha en el kernel de Linux mismo. Bajo este modelo, cada máquina virtual es un proceso regular de Linux, programado por el planificador entandar de Linux. Tradicionalmente, un proceso nonnal de Linux tiene dos modos de ejecución: kernel y usuario. El modo de usuario es el de defecto para las aplicaciones, y el de aplicación pasa a modo kernel cuando requiere de algunos servicios del kernel, tal como escribir al disco duro. KVM agrega un tercer modo, el modo de huésped. Los procesos en modo huésped son procesos que son ejecutados desde dentro de la máquina virtual. El modo huésped, tal como el modo nonnal (para una instancia no virtualizada), tiene su propio kernel y variaciones de espacio del usuario. Los comandos kili y ps tradicionales trabajan en modo huésped. Desde la instancia no virtualizada, una máquina virtual KVM es mostrada como un proceso nonnal, y puede ser detenida (killed) corno cualquier otro proceso. KVM hace uso de la virtualización de hardware para virtualizar los estados del procesador, y la administración de memoria para la máquina virtual es manejado desde dentro del kernel. La E/S en la es manejada en el espacio del usuario, primariamente a través de QEMU.

Una instalación típica de KVM consiste en las siguientes componentes:

• Un manejador de dispositivos para administrar el hardware virtual; este manejador expone sus capacidades vía un dispositivo tipo caracter /devlkvm.

21

• Una componente del espacio de usuario para emular el hardware PC; actualmente, esto es manejado en el espacio del usuario y es un proceso QEMU modificado ligeramente.

• El modelo de E/S es directamente derivado de QEMU, con soporte para imágenes de disco copy-on-write y otras características QEMU.

22

3. SEGURIDAD EN AMBIENTES VIRTUALES Linux ha proporcionado características de seguridad las cuales tienen su origen en el génesis de los sistemas Unix. Todos los sistemas basados en Unix tienen el concepto de super-usuario generalmente conocido como root. Este usuario tiene todos los poderes adinistrativos para administrar el sistema y todos los demás usuarios necesitan permiso del super-usuario para ejecutar acciones. Esto proporciona cierto grado de seguridad al restringir el alcance de las acciones de un usuario y por lo tanto limitando los daños que pueden ser causados. Así, solamente puede haber dos tipos de usuarios en un sistema Unix tradicional, un super-usuario y un usuario normal. El onus está en que el super-usuario restrinja el acceso no autorizado por los usuarios normales. Los privilegios en conjunto de acceso al sistema y el control está dado exclusivamente al super-usuario.

3.1 POLÍTICAS DE SEGURIDAD

La seguridad en los equipos de computo hoy en día se logra mediante la implementación de políticas de seguridad. Si se visualiza a la seguridad como una máquina de estados finito, entonces una política de seguridad es una afirmación que divide a los estados en seguro y no seguro.

De manera sencilla se pueden clasificar las políticas de seguridad en dos clases. La primera clase, políticas de seguridad discrecionales, son políticas de seguridad que cualquier usuario ordinario puede definir, alterar o asignar. La segunda clase, políticas de seguridad obligatorias, deben ser definidas y controladas de manera estricta por los administradores de los sistemas, implementadas a nivel sistema operativo.

Una política de seguridad puede hacer uso de dos tipos de control de acceso: Control de Acceso Discrecional (CAD) o Control de Acceso Obligatorio (CAO). Con CAD un usuario puede definir un mecanismo de control de acceso para conceder o para negar acceso a objetos de su propiedad. CAD basa los derechos de acceso en la identidad del sujeto y de la identidad del objeto involucrado, el dueño del objeto puede especificar cuales sujetos pueden acceder al objeto, con permisos particulares.

CAD es el enfoque tradicional adoptado por la mayoría de los sistemas Unix. La seguridad es impuesta a discreción del usuario. Las siguientes son algunas características de este modelo:

23

• El sistema consiste de un conjunto de usuarios y un conjunto de recursos en fom1a de archivos (o dispositivos).

• Los usuarios del sistema están asignados a uno o varios grupos de usuarios. Los grupos nos son mutuamente excluyentes.

• Cada objeto archivo es poseído por un usuario. Usualmente este es el usuario que crea el archivo.

• Cada objeto archivo es asociado con tres conjuntos de derechos de acceso. Estos conjuntos son lectura, escritura y ejecución cada uno teniendo tres bits.

• El propietario de un archivo puede definir los derechos de acceso para otros usuarios en el sistema ( que no estén en el grupo del propietario).

• El propietario de un archivo también puede definir los derechos de acceso para el mismo. • Con tres bits de derechos de acceso para cada una de las entidades de arriba, hay en total

nueve bits asociados con un objeto archivo dado.

Los sistemas prácticos demandan un método para la especificación de reglas mucho más flexible . CAD no es lo suficientemente flexible para especificar reglas complejas que un modelo de seguridad puede contener para una organización. También como el nombre sugiere la responsabilidad de asegurar la información está en el propietario o generalmente el usuario, de un sistema. Un usuario puede arbitrariamente asignar o transferir los derechos sobre un objeto a otros usuarios, violando la verificación sobre la información así como la política de seguridad por directorio. De aquí, la necesidad para CAO.

CAO es un conjunto de reglas para controlar el acceso basado directamente en una comparación de la autorización del individuo (clearance) para la información y la clasificación o designación de la sensitividad de la información que está siendo buscada, e indirectamente sobre consideraciones de factores fisicos y ambientales de control. Los controles de acceso obligatorio también toman el poder del usuario root tal como en_ un sistema Unix tradicional y sujeto a todos los usuarios, incluyendo los administradores, a las políticas de control de acceso del sistema. CAO garantiza que los protocolos de seguridad sean seguidos y limitan el daño en caso de compromiso.

Las políticas CAO son una característica de una organización dada. Por lo tanto solamente el marco de trabajo es usualmente proporcionado dejando que la organización dicte las políticas actuales.

En CAO cuando se define el control de acceso en un objeto, el dueño del objeto no puede modificar los derechos de acceso. En este caso, el Sistema Operativo (SO) es responsable de implementar el CAO, e inspecciona la información asociada tanto al sujeto como al objeto para determinar si se le concederá derecho de acceso al sujeto.

CAD es utilizado ampliamente por todos los Sistemas Operativos modernos dada su facilidad de uso y facilidad de administración. En CAD es imposible proteger al sistema en contra de código malicioso (como por ejemplo un caballo troyano) dado que dicho código obtiene los permisos de seguridad del usuario que los está ejecutando. Explotando estos derechos legítimos, el código malicioso obtiene acceso no autorizado a los recursos y archivos del usuario, y entonces puede

24

comprometer su confidencialidad e integridad. Aún peor, puede cambiar la política de CAD para abusar el sistema sin el consentimiento del usuario.

Para tratar los problemas de CAD, es necesario eliminarlos y emplear CAO. Con CAO un usuario malicioso ( o código malicioso) no podrá abusar de recursos para un propósito distinto al que especifica el sistema.

3.2 TRABAJOS RELACIONADOS EN CUANTO A SEGURIDAD OBLIGATORIA EN EQUIPOS AISLADOS

La solución más práctica en cuanto a arquitecturas CAO (en servidores fisicos aislados), se encuentra implementado en sistemas operativos, tal es el caso de Security Enhanced Linux (SELinux) [7], LIDS [8], Trustees [9] y AppArmor [10].

Las arquitecturas existentes de CAO se han diseñado e implementado en sistemas operativos aislados, tal como Linux [40] y FreeBSD [41]. En las arquitecturas CAO tradicionales el control de recursos se realiza en un estilo granular fino por lo que se dificulta de manera directa su extensión a un ambiente distribuido. También, las complejas políticas del CAO causa que algunas arquitecturas CAO, tal como SELinux [42], no puedan proveer un aislamiento fuerte para todas las aplicaciones en el sistema completo, soportando solamente la aplicación de CAO entre aplicaciones de baja escala.

SELinux [30] es un proyecto bajo el NSA para implementar CAO en Linux para propósitos militares. Sigue el modelo de La Padula para su arquitectura y también soporta RBACs (Rule Based Access Control). Debido a que es parte del kernel de Linux, se reducen los problemas de portabilidad. Emplea EA para etiquetar archivos en el sistema de archivos. También soporta contextos de seguridad para una aplicación dada. Una aplicación puede puede cambiar su contexto de seguridad durante el curso de su ejecución.

SELinux ofrece la solución más segura y ha sido incluida en el kernel de Linux durante los últimos años. Desafortunadamente, a pesar de que está disponible en todos los sistemas operativos Linux, SELinux es muy complicado de administrar: usualmente se requiere de un experto para desarrollar políticas SELinux. Por lo que muchas veces se recomienda que se deshabilite SELinux para usuarios no expertos, lo cual eventualmente puede comprometer sus sistema a vulnerabilidades. Muchas personas preferirían tener sus equipos sin tanta complejidad a pesar de no tener tanta seguridad. Lo que hoy día sigue siendo una pesadilla para los desarrolladores de SELinux: como hacer que un sistema sea seguro, pero al mismo tiempo fácil de utilizar por todo los usuarios. El expresar y el implementar un modelo simple de Base de Computo Segura en SELinux es muy dificil debido a las interdependencias entre procesos [13].

En contraste a SELinux, Trustees, AppArmor y LIDS son muy fáciles de administrar, aún para aquellos administradores que son nuevos en estos esquemas. Con el objetivo de ser una solución CAO fácil de utilizar, AppArmor implementa sus políticas en aplicaciones seleccionadas (contrario a SELinux que implementa sus políticas de manera global al sistema). La política de AppAnnor está basada en en rutas de sistema operativo y pueden ser declaradas de forma amigable en archivos de políticas.

25

Originalmente un proyecto llamado Subdomain [ 11] desarrollado por una compañía llamada Immunix, AppArmor ha sido adquirido por Novell y publicado bajo la licencia de código abierto GPL. Al momento, AppArmor atrae a un grupo de desarrolladores de código abierto los cuales están trabajando en un proyecto en el kernel de Linux como una alternativa a SELinux.

UDS adopta un enfoque similar al de AppArmor, pero de forma invertida: mientras que AppArmor pone las políticas encima de las aplicaciones, en el cual la política declara cuales archivos y que modos una aplicación en especifico puede acceder, UDS declara que aplicaciones pueden acceder un archivo en especifico. Subsecuente, mientras que LIDS parece estar más enfocado a proteger los datos en el sistema de archivos, AppArmor pone más atención en prevenir que las aplicaciones dañen el sistema de archivos. Otra diferencia es de que LIDS tiene como objetivo el de proveer protección a lo ancho del sistema, mientras que AppArmor solamente trata de proteger aplicaciones críticas, la mayor parte son servicios de red. Es por eso que AppArmor ha sido muy criticado por la comunidad de seguridad: si una aplicación local no protegida se compromete, el atacante le puede sacar provecho para atacar un equipo protegido, y comprometerlo fácilmente.

AppArmor en una implementación CAO para Linux también utilizando LSM [32,33]. Sin embargo AppArmor no utiliza EA para la identificación de archivos pero utiliza las rutas de archivo en su lugar. Similar a SMACK AppArmor permite los accesos read, write, link, file locking y file append. AppArmor también define reglas para los diferentes ejecutables (individual o como grupo) en el sistema. AppAm1or también tiene un modo de aprendizaje en donde una política se genera de manera automáticamente al observar las diferentes transacciones que se dan el sistema mientras se está en ese modo. Asigna perfiles por directorio. También especifica que una tarea o aplicación puede cambiar su contexto de seguridad cuando lo requiera siempre y cuando este autorizado para hacerlo.

AppArmor es superior a UDS en cuanto a su capacidad para confinar subprocesos: un thread dentro de una aplicación puede escoger cambiar la política (lo cual se le conoce como "hat" en terminología de AppArmor). Como resultado, AppArmor puede ser utilizado para implementar políticas separadas para una aplicación multi-hilos tal como el Servidor de Web Apache: con Apache, los scripts de PHP o Peri pueden ejecutarse con diferentes políticas de aislamiento del conjunto de políticas de Apache.

Trustees es un esquema CAO inspirado por NetWare. Pemúte que los administradores del sistema designen usuarios autorizados para cualquier directorio o archivo. Todos los subdirectorios o archivos en ese directorio también heredarán de la lista de control de acceso. Los derechos de los beneficiarios pueden ser modificados o extendidos dentro de los subdirectorios. Subsecuente, el control de acceso es implantado por parte de los beneficiarios también es basado en la ruta de los archivos del objeto.

Trustees está diseñado para reducir los requerimientos de mantener muchas listas de control de acceso en un sistema con muchos archivos y subdirectorios. También es dificil y demandante de tiempo la verificación de todas las listas de control de acceso. Al implantar un sistema con Trustees, el administrador solamente necesita especificar los derechos del sistema en un archivo de configuración pequeño para directorios específicos del nivel superior.

26

Todos los proyectos mencionados son posibles gracias a los ganchos proporcionados por el subsistema de seguridad de Linux (conocido corno Linux Security Module - LSM). LSM proporciona un marco de trabajo de control de acceso ligero y de propósito general para el núcleo de Linux. LSM permite que muchos modelos de control acceso diferentes sean implementados como modulo que se pueden cargar del núcleo [16,17]. LSM no proporciona ninguna política, lo que proporciona es un marco de trabajo en la forma de puntos de intercepción a lo largo del núcleo. Antes de que el núcleo pueda haber accedido un objeto interno, un gancho realiza una llamada a una función disponible por el modulo de LSM. El modulo puede permitir el acceso, o negar el acceso y provocar que un código de error sea regresado.

LSM fue adoptado dentro del kernel de Linux a partir de la versión 2.6.8. Cualquier sistema de seguridad requiere que se realice primero el control de acceso antes de que se conceda el acceso al recurso. Tal lógica de control de acceso tiene que estar aislada del espacio normal de usuarios. En los sistemas Linux los controles de acceso son realizados al embeber tal código dentro del kernel e invocando al mismo cuando una llamada del sistema sea invocada. El código de control de acceso administra todos los accesos a un recurso en particular. LSM aisla la lógica de control de acceso del espacio normal del usuario. Proporciona un conjunto de callbacks para cada llamada disponible al sistema en los sistemas Linux. Esto obliga a que todas las peticiones para un recurso dado pasen por una verificación de seguridad. Cualquier cambio a la lógica de control de acceso es inmediatamente reflejada en la siguiente petición. Un marco de trabajo de seguridad debe hacer uso del callback para implementar los controles de acceso necesarios.

Hay disponibles otras investigaciones relacionadas con el CAO, tal como FLASK (basado en SELinux), Simplified Mandatory Access Control Kernel (SMACK) [31], Lothlorien, RSBAC [20] y Grsecurity[21].

El proyecto SMACK [31] emplea LSM para implementar CAO. También utiliza EA para etiquetar los archivos en el sistema. Sin embargo divide al sistema basado en cuatro etiquetas por defecto. SMACK está actualmente soportado en el kernel de Linux. No divide explícitamente el sistema en partes lógicas pero construye slightly upon los modos existentes de acceso i.e. Lectura, escritura y ejecución y agrega más modos de acceso tal como append y combinaciones del acceso como read, write, etc.

Lothlorien [ 45] es esencialmente un LSM el cual intenta lograr lo siguiente:

• Implementar CAO en un sistema Linux entandar. • Proveer un mecanismo flexible de políticas. • Lograr al menos el nivel TCSEC B 1 de estándares de seguridad.

Lothlorien está pensado para ser ejecutado en un sistema base sobre el cual se apoya en varios modelos de seguridad. Lothlorien está pensado para soportar todas las primitivas básicas para permitir que las políticas sean escritas y probadas.

27

RSBAC [34] es un proyecto inspirado en el Modelo La Padula de Bell para seguridad. Especifica un kernel de seguridad [35]. No utiliza LSM completamente pero, en vez de eso implementa sus propios ganchos y se enfoca en el control de acceso basado en roles [36,37].

Hay varias instancias de sistemas operativos (aislados) altamente seguros que han sido comercializados de manera exitosa -e.g., GEMSOS, KSOS, Trusted BSD, o Multics [14]- no se ocupan ampliamente. El enorme diseño, desarrollo, y costo de evaluación se justificó solamente para los dominios especializados de aplicación con requerimientos muy altos de seguridad. El control de acceso y la granularidad a nivel archivo en sistemas operativos de propósito general , es posible; sin embargo, es muy complejo tal como lo demuestran las políticas de SELinux [16].

Los proyectos de Trusted BSD tiene el objetivo de implementar CAO en variantes de BSD del sistema operativo Unix [38]. Hewlett-Packard utiliza la aplicación de contención de seguridad para implementar CAO en su versión de Unix HP-UX [39]. El proyecto Flexible Mandatory Access Control (FMAC) está bajo desarrollo para la versión código abierto de Solaris, el proyecto Open Solaris.

3.3 TRABAJOS RELACIONADOS EN AMBIENTES VIRTUALES

Los Monitores de Máquinas Virtuales (MMV) pueden ser un suplemento a la seguridad del sistema operativo y proporcionar confinamiento en caso de que fallen los controles de seguridad del sistema operativo.

Basado en MVs, un equipo fisico puede implementar un sistema multinivel de seguridad al dividirlo en múltiples sistemas virtuales, garantizando la separación de la seguridad. Originalmente el "Orange Book" definió políticas de seguridad multinivel para el Departamento de Defensa de los Estados Unidos [6]. Los núcleos de separación con MMV aislan completamente a las máquinas virtuales. NetTop [15] implementa sistemas virtuales que están aislados uno del otro en un mismo equipo fisico para permitir el procesamiento de datos pertenecientes a múltiples niveles sensibles en un mismo sistema.

Una MV puede compartir recursos virtuales con otras MVs (e.g., discos virtuales) o comunicarse con otros equipos a través de mecanismo de memoria compartida. Pero tales comportamientos deberán ser examinados cuidadosamente para prevenir la violación a la propiedad de aislamiento entre máquinas virtuales. Al implementar CAO en la infraestructura de virtualización se pueden coordinar los conflictos mencionados arriba de manera efectiva, reduciendo la posibilidad de la violación, y proveer una capacidad de protección más efectiva que el aislamiento tradicional de las MVs [28].

El aislamiento total no es deseable dado que las organizaciones de hoy día requieren comunicación entre las cargas de trabajo de las aplicaciones. Consecuentemente hay una necesidad para compartir recursos de manera segura al implementar un control de acceso entre grupos relacionados de máquinas virtuales.

Mientras que los flujos de información explicita entre MVs son controlados por políticas CAO, los flujos de infonnación implícita, llamados canales secretos (covert channels), no deberían ser

28

ignorados. Generalmente, los canales secretos existen entre las MVs, tal como el acceso a recursos compartidos (llamados canales de almacenamiento) u operaciones con canales sincronizados, con dificultad de ser identificados y alta imposibilidad de ser eliminados completamente [28].

En los proyectos Type Enforcement [43], Multi-Level Security (MLS) [44] se divide el sistema de máquinas virtuales en varios subsistemas de MV con diferentes niveles de seguridad. Cada subsistema de cierto nivel de seguridad puede ser desplegado con políticas CAO especificas.

Shamon [48], un sistema CAO construido en el sistema de máquinas virtuales de Xen, implementa CAO en dos capas: (1) el Xen VMM (sHype [18] MAC) que controla el acceso a recursos entre MVs, y (2) SELinux y la red de IPSec. Shamon no provee un control de canal encubierto dado que ninguna política CAO especifica se proporciona para controlar el canal encubierto en el sistema completo.

Cuando se implementan políticas CAO en ambientes virtuales de computo distribuido, el problema con las actuales arquitecturas es que carecen de la base de computo confiable (TCB), lo cual reduce la credibilidad de las funciones de autorización utilizadas por varios sistemas administradores de confianza [46,47]. DVM-MAC está construido con soporte TCB y puede resolver el problema de seguridad que se da del canal encubierto [28].

Mediante la arquitectura VMAC [29] se ponen todas las políticas MAC de todos los huéspedes virtuales en una VM administrativa. El monitor de referencia en los kernels de estos huéspedes virtuales se modifican, 1 de tal manera que las políticas MAC sean descargadas de la VM administrativa. Desde la VM administrativa se actualizan las políticas de cualquier VM. La plataforma de virtualización empleada por VMAC es Xen.

En la arquitectura VMAC todos los registros de seguridad son enviados a la VM administrativa. La VM administrativa es protegida de manera segura2 de tal forma que el atacante no tiene oportunidad de explotar los datos inmunes, aún cuando tome totalmente la caja virtual.

En VMAC cada VM reserva un área de memoria y la comparte con la VM administrativa. La memoria es utilizada para intercambiar información con la VM administrativa. La VM puede poner en cache las políticas en la memoria interna del kernel, y solamente limpiar y actualizar el cache cuando hayan peticiones de actualización por parte de la VM administrativa .

Todos los registros de control de acceso desde las VMs son enviados a la VM administrativa, empleando la misma memoria compartida . La memoria compartida la divide en dos mitades, una nútad para intercambiar políticas de seguridad y la otra mitad para los datos de registros.

I La modificación se limita solamente al subsistema de seguridad. 2 La VM administrativa puede ser considerada que pertenece al TCB (Trusted Computing Base), la componente

principal requerida para implementar la política de seguridad del sistema.

29

3.4 SOLUCIÓN PROPUESTA

El tamaño y complejidad de las organizaciones de hoy en día hace casi imposible mantenerse al ritmo del cambio en cuanto al rubro de seguridad en TI, lo cual requiere una estrategia de arriba hacia abajo que le de prioridad a los riesgos y acepte las limitaciones de las tecnologías actuales. Solamente a través de la adopción de políticas de seguridad centralizada de alto nivel las organizaciones podrán hacer frente a los riesgos de seguridad.

En este desarrollo de tesis se emplea una noción más general de la noc1on de seguridad obligatoria, en el cual una política de seguridad se considera obligatoria si la definición de la política y la asignación de atributos de seguridad están controlados por un administrador del sistema.

Este trabajo de tesis propone una arquitectura llamada Políticas de Seguridad Centralizadas para Máquinas Virtuales (PSCMV) VMWare; mediante la implementación de Controles de Acceso Obligatorio en Ambientes Virtuales (CAOV); de tal forma que la administración de políticas CAO se realice de manera sencilla y flexible desde un huésped virtual administrativo.

Como resultado, el actualizar el CAO para huéspedes virtuales resulta sencillo, dado que se realiza desde una ubicación central. En el huésped virtual central se cuenta con una base de datos MySQL en la que se registran las políticas de seguridad .de todos los huéspedes virtuales. Las políticas son administradas desde el huésped administrativo. El administrador puede localmente actualizar las políticas de cualquier huésped virtual en cualquier momento.

La comunicación entre los huéspedes virtuales y el huésped virtual administrativo se realiza mediante la librería de VMware VMCI sockets. Los VMCI sockets de Vmware es un API similar a los sockets de Berkeley {UNIX) y los sockets de Windows. Los VMCI sockets soportan una comunicación rápida y eficiente entre máquinas virtuales.

La arquitectura propuesta es una combinación de dos ideas: CAO y virtualización a nivel sistema operativo.

Dado que toda la información sobre políticas son intercambiados entre los huéspedes virtuales y el huésped virtual administrativo vía VMCI sockets, el proceso incurre en muy poca sobrecarga. La parte de red nunca es utilizada para intercambiar datos entre los servidores virtuales. Esta estrategia evita que el tráfico sea analizado, lo cual podría pasar si se utilizará la red para enviar datos.

PSCMV se compone de tres serv1c10s, un repositorio de políticas CAO y un canal de comunicación de alta velocidad: el servicio de obtención de políticas, llamado SOP en cada huésped virtual y el servicio de transmisión de políticas de seguridad, llamado STP en el huésped virtual administrativo.

El servicio SOP de cada huésped virtual es responsable de actualizar localmente las políticas CAO. SOP obtiene sus políticas actualizadas a partir del servicio STP, el cual está en ejecución

30

en el huésped virtual administrativo. SOP también emplea el canal de comunicación para solicitar al huésped virtual administrativo el refrescado de políticas.

Este servicio STP se inicia en tiempo de arranque en el huésped virtual administrativo. El servicio transmite las políticas CAO a los huéspedes virtuales. La transmisión de políticas CAO hacia los huéspedes virtuales se lleva a cabo de manera periódica utilizando el canal de alta velocidad.

3.5 COMPARACION CON OTRAS PROPUESTAS

En [29] cada huésped virtual que desee centralizar sus políticas de seguridad y ser administrado por un equipo central debe asignar un área de memoria y compartirla con el equipo central. Esta memoria es utilizada para intercambiar infonnación: cuando se recibe una petición del huésped virtual para la política de seguridad, el huésped virtual administrativo pone la política correspondiente en la memoria compartida y notifica al huésped virtual para tomarla. Cuando el huésped virtual administrativo quiere ajustar las políticas de un huésped virtual especifico, infonnará a ese huésped para que se descarten las políticas anteriores y tomar las nuevas políticas que se depositen en la memoria compartida. Toda la infonnación acerca de las políticas son intercambiadas vía la memoria compartida, la red nunca es utilizada para intercambiar infonnación.

En PSCMV las políticas CAO son almacenadas en una base de datos relacional y transmitidas utilizando un canal de alta velocidad (VMCI sockets). PSCMV se implementa el esquema de TOMOYO; mientras que en [29] se implementa mediante los esquemas AppArmor, LIDS y Trastees. En PSCMV la platafonna de virtualización utilizada es VMWare, en [29] la platafonna de virtualización es Xen. En [29] se transmiten registros de control de acceso de los huéspedes virtuales hacía el huésped virtual administrativo, en PSCMV no se transmiten los registros de control de acceso. En PSCMV se manejan las ventanas de servicio, en [29] no se manejan ventanas de servicio.

En [ 48] el esquema CAO que se utiliza es SELinux, en PSCMV el esquema utilizado es TOMOYO. En [48] no se provee de un canal encubierto para la transmisión de políticas CAO; mientras que en [29] así como en PSCMV la transmisión de políticas se realiza en un canal seguro.

[ 15] implementa sistemas virtuales que están aislados uno del otro en un mismo equipo para pennitir el procesamiento de datos pertenecientes a múltiples niveles de sensibilidad, con [29] y PSCMV también se pueden manejar huéspedes virtuales totalmente aislados ya que no es necesario que utilicen la red para comunicarse.

TOMOYO es un mecanismo CAO. Al igual que en [16] y [10], TOMOYO controla el comportamiento de los programas con la idea de contener cualquier vulnerabilidad de seguridad dentro de los programas. TOMOYO y [10] las políticas se describen en ténninos de rutas para la protección del sistema.

TOMOYO fue seleccionado para el esquema CAO en vez de [10] por las siguientes razones:

31

a) El modo CAO en [10] es por programa; mientras que en TOMOYO es por dominio (que es lo mismo que el programa con toda la cadena de llamadas).

b) En [10] los objetos CAO solamente confina a los procesos que la política dicta, en TOMOYO los objetos CAO son los mismos que SELinux.

c) En [10] la definición del dominio es manual, en TOMOYO la definición del dominio es automática.

d) En [10] la generación de políticas es por medio de una utileria (genprof) y un editor; mientras que en TOMOYO la generación se realiza en modo de "aprendizaje".

32

4. DISEÑO DE LA ARQUITECTURA PSCMV

La arquitectura PSCMV está basada en dos paradigmas, la virtualización a nivel sistema operativo basada en VMWare Server y políticas CAO (Control de acceso obligatorio). En esta arquitectura la administración de políticas de seguridad se realiza de manera sencilla y flexible desde una huésped virtual administrativo.

PSCMV está compuesto de cuatro servicios, un repositorio y un canal de comunicación de alta velocidad: el servicio de planificación, el servicio de obtención de políticas, llamado SOP en cada huésped virtual; el servicio de transmisión de políticas de seguridad, llamado STP en el huésped virtual administrativo; el repositorio de políticas CAO; el servicio de administración del repositorio y el canal de comunicación de alta velocidad.

4.1 SERVICIO DE PLANIFICACIÓN

Este servicio se inicia en tiempo de arranque del master node y se encuentra en ejecución en todo momento. El servicio de Planificación se encarga de agendar la transmisión de políticas CAO al servicio STP. Este servicio realiza las siguientes operaciones:

• Invocación del servicio STP durante las ventanas de tiempo especificadas por el objeto windows del repositorio de políticas CAO.

• Invocación del servicio de Polling para determinar los servidores activos (solamente a los servidores activos les serán enviadas las políticas CAO).

33

Servicio de Planlflcaclón Repositorio Polllng Servtce

1 Solicitar ventanas de operación

1 1 Ventanas de operación

Solicitar servidores activos

' Servidores activo 1 ~e,--~~~~~~~---~~~~~~~

Figura 1. Servicio de Planificación

4.2 SERVICIO STP

Este servicio se inicia en tiempo de arranque en el huésped virtual administrativo. El servicio realiza las siguientes operaciones:

a) Transmisión de políticas CAO a los huéspedes virtuales (programado y bajo demanda -a petición del administrador del dominio de seguridad) b) Consulta del repositorio CAO.

La transmisión de políticas CAO hacia los huéspedes virtuales se lleva a cabo de manera periódica utilizando el canal de alta velocidad; asimismo, el administrador del dominio de seguridad (administrador del equipo central) podrá solicitar el envío de políticas CAO bajo demanda (cuando lo considere pertinente - por ejemplo cuando acaba de actualizar el repositorio de políticas CAO).

La operación de transmisión de políticas CAO realiza las siguientes funciones: • Por cada uno de los servidores activos se realiza lo siguiente:

o Realiza la operación de consulta para determinar las políticas que serán transmitidas. Las políticas que son candidato a transmisión son aquellas que tienen el estado de "pending"

o Transmitir el lote de políticas con estado pending. o Por cada política CAO que se transmite del master node al huésped virtual se calcula

su código hash. El huésped virtual también calcula el código hash de cada una de las políticas CAO recibidas. El código hash calculado en el huésped virtual se transmite al master node para ser comparado contra el código hash generado inicialmente por el master node.

34

O Una vez que se validan todos los códigos hash tanto del master nade como del huésped virtual, se cambia en el repositorio el estado de las políticas CAO que fuerón transmitidas a "applied'', de lo contrario se dejan las políticas en "pending" para reintentar la transmisión durante la siguiente ventana de transmisión. Asimismo se transmitirá el mensaje "verified'' al huésped virtual.

Servicio de Obtención de Polftlcas CAO

1

1

Calcular hash de la política CAO

recibida -

Transmitir política CAO (estado pena,ngJ

Enviar hash de la política CAO recibida

Políticas verificadas. Verlfied

Servicio de lransmlsión de Polltlcas CAO

1 Consulta de políticas CAO del servidor

Repositorio

1 ,~~~~~~~~~___,.

1 Políticas CAO del servidor

Calcular hash de la polftlca CAO

transmitida

Todas las polit,cas CAO ruerón verificadas

51. transmitir la siguiente política CAO

No. abortar la transmisión de poliicas CAO y dejar en pendlng el repositorio

Figura 2. Operación de transmisión de políticas CAO

4.3 SERVICIO SOP

Este servicio se inicia en tiempo de arranque en cada uno de los huéspedes virtuales que forman parte del dominio de administración. El servicio está dado de alta en TOMOYO, de tal manera que se puedan actualizar en tiempo real las políticas CAO del huésped virtual. Por lo tanto el servicio SOP forma parte del dominio local se seguridad.

El servicio SOP actualiza en tiempo real las políticas CAO locales a partir de las políticas transmitidas por el servicio STP. La actualización de políticas CAO se realiza en el dominio de

35

TOMOYO, la actualización o la inserción de nuevas políticas CAO se refleja primero a nivel kernel (en ejecución) y posteriormente a nivel archivos de configuración de TOMOYO.

El servicio realiza las siguientes operaciones:

a) Validación del master node. b) Recepción de políticas CAO c) Aplicación local de políticas CAO.

La operación de validación del master node realiza las siguientes funciones: • Durante la fase de "acksendcao" se genera un challenge number en el huésped virtual, el

challenge number se transmite concatenado al mensaje acksendcao. • El master node recibe el challenge number y lo almacena en el sistema de archivos local.

El master node procede entonces a firmar el challenge number empleando un hash sha256, el master node firma con su llave privada.

• El mensaje finnado se convierte a un huella de texto para que pueda ser transmitido por el canal de alta velocidad (empleando la técnica de uuencode).

• Una vez que el huésped virtual recibe el mensaje firmado como huella de texto, se procede a convertir de huella de texto a huella binaria.

• La huella binaria recibida del master node se valida para verificar si el master node realmente firmo el challenge number enviado inicialmente. La verificación se realiza mediante openssl, la llave pública del master node y el challenge number generado en el huésped virtual.

• Si la verificación resulto correcta se procede a la recepción de las políticas CAO.

Huésped Virtual

1 1

Generar challenge number

Verificación del mensaje firmado

por Master Nade

Master Nade

mensaje sendcao

mensa e ack:sendcao<challengeNumber>

1 1

1

.... ,r

Transmitir challenge firmado por el Firmar challenge Master nade Number con llave ~ - privada y convertir a

huella de texto

Figura 3. Operación de validación del master node

36

La operación de recepción de políticas CAO realiza las siguientes funciones: • Invocar la operación de validación del master node.

• Recibir las políticas CAO del huésped virtual. o Solicitar inicio de trasmisión de políticas CAO a master node. O Por cada política CAO que se recibe del master node, se calcula el código hash sha256

y se envía de regreso al master node para validar la integridad de la transmisión. o Todas las políticas recibidas se almacenan en un archivo de configuración (en el

sistema de archivos local). O Al fipalizar la transmisión de políticas CAO por parte del master node, se recibe la

señal de fin de transmisión. o Si se recibe el mensaje de verified por parte del master node se procede a aplicar

localmente las políticas CAO recientemente obtenidas. Primero se aplican a nivel kernel (en ejecución) y posteriormente se aplican a nivel archivos de configuración de TOMOYO.

- ..... < - ..... 1 I Sistema local

de I archivos

..... r..,

Aplicar políticas CAO

Almacenar politicas CAO en el sistema local de archivos

Aplicar localmente las políticas CAO

Huésped Virtual

1 1

Validación del Master Node

Figura 4. Operación de recepción de políticas CAO

TransmiSión de políticas CAO

Mensaje datend fin de TX de políticas CAO

Master Nade

1

1

37

La operación de aplicación local de políticas CAO realiza las siguientes funciones: • Las políticas almacenadas en el archivo de configuración se aplican a nivel kernel.

• Almacenar en los archivos de configuración de TOMOYO las políticas CAO representadas por los kemels en memoria.

- ...... < - ...... 1 I Sistema local

de I archivos

....... r ..., Leer políticas CAO recibidas por STP

Servicio de Obtención de Politlcas CAO

1

1 1

f

1

Aplicar politlcas CAO a nivel Kernel

Aplicar politicas CAO al dominio de seguridad (archivos de configuración)

Figura 5. Operación de aplicación local de políticas CAO

4.4 REPOSITORIO DE POLÍTICAS CAO

TO MOYO

1

1 1

El repositorio CAO es administrado por el SAR (Servicio de Administración del Repositorio). El repositorio de políticas CAO está contenido en un RDBMS (Relational Database Management System). El repositorio es administrado por el SAR. El repositorio no puede ser consultado directamente por los huéspedes virtuales, la única manera como podrán descargar/consultar sus políticas CAO es mediante el servicio STP ( el cual se encuentra en ejecución en el huésped virtual administrativo).

El repositorio almacena información de los siguientes objetos:

a) servers b) kemels c) kemel__policies d) server __policies e) parameters f) windows

38

El objeto servers representa los servidores huéspedes que forman parte del dominio de seguridad. Por cada servidor se requieren los siguientes atributos: id (identificador), hostname (nombre del servidor), ip ( dirección IP), status ( estado del servidor - active/inactive) y os ( Operating system installed- e.g. Ubuntu).

El objeto kernels representa los kernels disponibles en el dominio de TOMOYO. Cada tupla contiene los siguientes atributos: id (identificador del kernel) y path (ruta del kernel).

El objeto kernel_policies define las políticas CAO asociadas a cada uno de los kernels. Cada entrada de este objeto se define por medio de los siguientes atributos: kernel_id (identificador del kernel), policy _sec (secuencial) y policy _ val (representa la política CAO).

El objeto windows es utilizado para determinar la frecuencia de invocación del serv1c10 de transmisión de políticas CAO (STP). La ventana se define por medio de los siguientes atributos: server_id (identificador del servidor), {hour,min} (momento de invocación).

El objeto server_policies asocia el objeto kernels con el objeto servers; esto es, por cada servidor se listan los kernels que serán transmitidos. Adicionalmente contiene el resultado de haber transmitido las políticas CAO del master node hacía los huéspedes virtuales. Cada tupla se identifica por los siguientes atributos: server_id (identificador del servidor), kernel_id (identificador del kernel) y status (estado de aplicación de la política CAO en el servidorpending/applied).

El objeto parameters galmacena los parámetros generales de configuración. Cada renglón se compone de los siguientes atributos: param _ name (nombre del parámetro) y param _ value ( valor del parámetro).

4.5 SERVICIO DE ADMINISTRACIÓN DEL REPOSITORIO

Este servicio es consumido por parte del servicio STP. Mediante este servicio se habilitan las siguientes operaciones para manipular el repositorio:

a) Administración de servidores. b) Administración de políticas CAO. c) Administración de ventanas de aplicación. d) Administración de configuraciones.

La funcionalidad disponible para la operación "administración de servidores" es: • Consulta de servidores • Modificación de servidores • Inserción de nuevos servidores • Eliminación de servidores

39

serveR

•id •hostname l •ip •status •os

I Wlndows

•serverid

> aerver ""'lclea

•server id •kernel id •status

•-

r kernel llcles

•kernel 1d •policy _ sec • ol1c val

Figura 6. Objetos del repositorio de políticas CAO

La funcionalidad disponible para la operación "administración de políticas" es: • Consulta de políticas CAO • Modificación de políticas CAO • Inserción de nuevas políticas CAO • Eliminación de políticas CAO

La funcionalidad disponible para la operación "administración de ventanas de aplicación" es: • Consulta de ventanas de aplicación • Modificación de ventanas de aplicación • Inserción de nuevas ventanas de aplicación • Eliminación de ventanas de aplicación

La funcionalidad disponible para la operación "administración de configuraciones" es: • Consulta de configuraciones • Modificación de configuraciones • Inserción de nuevas configuraciones • Eliminación de configuraciones

40

,Ta.bla l. Funcionalidad del Servicio de Acl111ini_stración del Repositorio por ti_p()_ci_e o_peración Operación Consulta Modificación ! Inserción Eliminación

Administración de servidores

Administración de políticas

Administración de ventanas

Administración de configuraciones

X

X

X

X

4.6 CANAL DE AL TA VELOCIDAD

X

X

X

X

X

X

X

X

X

X

X

X

Los VMCI sockets son similares a otros tipos de sockets. Similar a los sockets de UNIX, los sockets de VMCI funcionan en máquinas fisicas individuales, y pueden realizar una comunicación entre procesos en el sistema local. Con los sockets de Internet, los procesos de comunicación usualmente residen en diferentes sistemas a lo largo de la red. Similarn1ente, los sockets de VMCI permiten que diferentes huéspedes virtuales se comuniquen entre sí, siempre y cuando residan en el mismo huésped VMWare.

La librería de VMCI sockets soporta tanto los sockets orientados a la conexión como TCP, y los sockets orientados a la no conexión como UDP. Sin embargo, con los sockets de VMCI, un socket virtual solamente pueden tener dos endpoints y a diferencia de los sockets de TCP, el servidor no podrá iniciar una conexión al cliente.

Los VMCI sockets permiten la comunicación de huésped a huésped, o del huésped al host. También se pueden utilizar los sockets de VMCI para comunicaciones entre procesos en un mismo huésped. Sin embargo, no se podrán utilizar sockets de VMCI entre dos huéspedes que se estén ejecutándose en máquinas fisicas separadas.

Como canal de comunicación se selecciono VMCI sockets por las siguientes razones:

• Mejoran la privacidad de la transmisión de datos en huéspedes virtuales • Tienen mejor desempeño que las aplicaciones basadas en sockets tradicionales • Proporciona un canal alterno para realizar tareas administrativas en los huéspedes

virtuales • Implementan una comunicación basada en red para huéspedes virtuales (aún para

huéspedes que no tengan configurado la parte de red) • El modificar una aplicación existe de sockets resulta muy sencillo

4. 7 PROTOCOLO DE COMUNICACIÓN

El protocolo de comunicación que se utiliza entre los huéspedes y el master node esta basado en Stream VMCI Sockets. La Figura 7 muestra como se establece la conexión entre los huéspedes y el master nade.

41

Huésped virtual

SOC ket()

V

Nodo Maestro bind()

socket() 'I

listen(}

context ID 'I

accept()

-,.. connect(} ,, selecto

w 1' recv() ~ send() -

send() - recv() -

' t p

el ose() el ose()

Figura 7. Stream Socket Orientado a Conexión.

4. 7.1 FUNCIONES UTILIZADAS POR EL HUÉSPED VIRTUAL

En una aplicación de sockets VMCI, se obtiene la nueva familia de direcciones (dominio) para reemplazar a AF _INET.

42

La llamada a bind() asocia al stream socket con los settings de red en la estructura sockaddr _ vmstructure, en vez de la estructura sockaddr _ in.

La estructura sockaddr _ vm contiene un elemento para context ID (CID), el cual especifica la máquina virtual. Para el huésped virtual esto es el CID local. Para el master nade (listener), esto podría ser cualquier huésped virtual que se está conectando. Tanto VMADDR_CID_ANY como VMADDR_PORT_ANY están predefinidos de tal fom1a que en tiempo de bind o de conexión, el CID y puerto apropiado sean llenados a partir del huésped virtual. VMADDR_CID_ANY es reemplazado con el CID de la máquina virtual y VMADDR_PORT_ANY proporciona un puerto del rango no reservado (>=1024).

El nodo maestro ( conector) puede obtener su CID local llamando VMCISock _ GetLocalCID().

La función bind() es la misma que se utiliza en aplicaciones tradicionales de TCP sockets.

La llamada listen() prepara al huésped virtual para recibir conexiones entrantes de los huésped virtuales. La macro BACKLOG predefine el número de conexiones que el sistema acepta antes de rechazar nuevas. Está función es la misma que listen() en aplicaciones regulares TCP.

La llamada accept() espera indefinidamente() a que lleguen las conexiones entrantes, creando un nuevo socket (y descriptor de stream) cuando llegue la conexión del nodo maestro. La estructura their addr se llena con información de la conexión.

La llamada recv() lee los datos desde la aplicación huésped virtual. El huésped virtual y el nodo maestro pueden comunicar la longitud de los datos transmitidos, o el huésped virtual puede tenninar su ciclo recv() cuando el huésped virtual cierre su conexión.

La llamada send() puede escribir datos a la aplicación huésped virtual. Tanto el huésped virtual como el nodo maestro deben comunicar la longitud de los datos transmitidos, o estar de acuerdo en un tamaño con anticipación. Frecuentemente el huésped virtual envía solamente infonnación de control a el nodo maestro.

La función close() cierra el socket y termina la conexión en caso de que este todavía abierta. Algunas aplicaciones de tipo servidor cierran inmediatamente después de recibir los datos del huésped virtual, mientras que otras esperan conexiones adicionales.

4.7.2 FUNCIONES UTILIZADAS POR EL NODO MAESTRO

En una aplicación de sockets VMCI, se obtiene la nueva familia de direcciones (dominio) para reemplazar a AF _INET.

La llamada connect() solicita una conexión tipo socket al huésped virtual especificado por CID en la estructura sockaddr _ vm, en vez de la dirección IP en la estructura sockaddr _ in.

La llamada send() escribe datos a la aplicación huésped virtual. El huésped virtual como el nodo maestro pueden comunicar la longitud de los datos transmitidos, o el huésped virtual puede terminar su ciclo recv() cuando el huésped virtual cierre su conexión.

43

La llamada recv() lee datos de la aplicación huésped virtual. Algunas veces el huésped virtual envía información para el control del flujo, de tal forma que el huésped virtual debe estar preparado para recibirla. Emplear el mismo descriptor de socket que para send().

La llamada clase() termina una conexión, dado el descriptor de socket original obtenido de la función socket().

4.8 POLÍTICAS CAO EN LOS HUÉSPEDES VIRTUALES

En el 2009 se incluyó en el kernel de Linux en la versión 2.6.30 (Junio 2009) [ 49]. En TOMOYO un dominio de seguridad es simplemente definido por una cadena de llamadas realizadas por un proceso, y representado por medio de una cadena (etiqueta). TOMOYO trabaja en 4 modos: disabled, learning, permissive y enforcing. Los administradores pueden asignar diferentes modos para diferentes dominios. TOMOYO Linux introdujo el modo "learning" ( o aprendizaje), en el cual los accesos ocurridos en el kernel son automáticamente analizados y almacenados para generar una política CAO: este modo puede ser utilizado como un primer paso para la escritura de políticas, fáciles de personalizar más adelante.

Las políticas CAO se implementan localmente en los huéspedes virtuales mediante TOMOYO Linux. TOMOYO Linux es una implementación CAO ligero para Linux y Linux Embebido desarrollada por la compañía Japonesa NTT Data Corporation. Realiza CAO basado en rutas, separando los dominios de seguridad acorde al histórico de invocación de procesos, lo cual describe el comportamiento del sistema. Las políticas son descritas en términos de rutas. Cada proceso pertenece a un solo dominio, y básicamente el proceso pasara por diferentes dominios cuando ejecute un programa. El nombre de un dominio es una expresión de cadena concatenada para el histórico de ejecución de procesos.

TOMOYO Linux concede los permisos de acceso por dominio. Es administrado vía /sys/kernel/security/tomoyo/domain_policy. En TOMOYO Linux, cada proceso pertenece a un solo dominio, y todos los programas pertenecen a diferentes dominios. Aun cuando dos procesos estén ejecutando el mismo programa, si su dominio previo difiere, entonces pertenecen a un dominio diferente.

Todos los dominios están definidos a partir del dominio "<kernel>", al cual el proceso del kernel pertenece. Dado que /sbin/init is invocado por el dominio "<kernel>", el dominio para /sbin/init es definido como "<kernel> /sbin/init". Dado que /etc/rc.d/rc es invocado por /sbin/init, el dominio es definido como "<kernel> /sbin/init /etc/rc.d/rc".

4.8.1 TRANSICIÓN DEL DOMINIO DE TOMOYO

Cuando un proceso intenta ejecutar un programa, se ejecutan los pasos listados en la tabla 2 y 3.

44

Tabla2. Transició11del dominio de_TOMQYQ,_p!!!1~L-

i Paso

Obteniendo el nombre del programa

Agregando programas similares

Verificar permisos

Decidir el dominio destino

Procedimiento

Obtener el nombre del programa que el proceso va a ejecutar y mantenerlo como "Candidato". Este procedimiento no resuelve ligas simbólicas en caso de que el programa sea una liga simbólica.

Buscar en excepción a las políticas: • aggregator "Candidato" "aggregated name"

! y sí se encuentra uno, reemplazar "Candidato" con "aggregated narne". ---- - ---·-----···- ----·--·-··-·-·-·-----·· ·-

. Buscar en la política del dominio: • allow execute "Candidato" • allow _ execute @"a pathname group containing Candidato"

y negar la petición de ejecución sí no se encuentra alguna. ------- ---· -----·-

(1) Buscar en exception policy: • no_initialize_domain "Candidato" from "the name ofthe domain the current

process belongs to" • no_initialize_domain "Candidato" from "the last part ofthe name ofthe domain

the current process belongs to" • no_initialize_domain "Candidato"

y sí se encontró uno, bifurcar al paso (3).

i (2) Buscar en exception policy: • initialize _ domain "Candidato" from "the name of the domain the current

process belongs to" • initialize_domain "Candidato" from "the last part ofthe name ofthe domain the

current process belongs to" • initialize_domain "Candidato"

y sí encontró uno, concatenar "el nombre del dominio al que pertenece el kernel ( e.g. <kernel>)" y "Candidato" y mantener el resultado como dominio destino, entonces bifurcar al paso (6).

· (3) Buscar en exception policy: • no_ keep _ domain "Candidato" from "the name of the domain the current process

belongs to" • no_keep_domain "Candidato" from "the last part ofthe name ofthe domain the

current process belongs to" • no_keep_domain "the name ofthe domain the current process belongs to" • no_ keep _ domain "the last part of the name of the domain the current process

belongs to" y sí encuentra uno, bifurcar a (5).

(4) Buscar en exception policy: • keep _ domain "Candidato" from "the name of the domain the current process

belongs to" • keep_domain "Candidato" from "the last part ofthe name ofthe domain the

current process belongs to" • keep_domain "the name ofthe domain the current process belongs to" • keep_domain "the last part ofthe name ofthe domain the current process

belongs to" y sí encontró uno, ajustar "el nombre del dominio al que pertenece el proceso actual"

J como dominio ~e_~ti~? e~t?.'1c_e_s bifurcar a (6).

45

l1!1Jla 3. J~ansici§n deU:iQl!lif!ÍQ_Q~JQ_MQYQ, ~1ute 2 __________ _

1

P~~--- _____ _____________ __¡Procedimiento__ _ _________________ _

'Decidir el dominio destino ! (S) Concatenar "el nombre del dominio al cual pertenece

i ¡-------·-·---------------· -

Ejecutar el programa

. j el proceso actual" y "Candidato" y mantener el resultado I como el dominio destino.

• (6) Verificar sí el dominio destino está definido, y negar __ ----V! p~tici~11_~~-e¡~~~~~ó_n_e_11 C_'.':S~~~ q~~no esté d~finido.

! Realizar los pasos regulares para la ejecución del programa. Sí se completa exitosamente, el proceso transitará hacía el dominio destino.

4.8.2 POLÍTICAS CAO SOPORTADAS EN LOS HUÉSPEDES VIRTUALES

El archivo /sys/k.emel/security/tomoyo/domain_policy contiene la definición de todos los dominios y permisos concedidos a cada dominio.

Todas las líneas contenidas entre la definición de un dominio (cualquier línea que empiece con "<kernel>") y hasta la línea previa al inicio del siguiente .dominio son interpretadas como permisos de acceso para ese dominio.

En la tabla 4 se muestran las directivas de configuración del archivo domain_policy.

T.i]?JaA. lli!t?Ct!\'.<l~ Qt? confi~i:ación del archi~C> do111~_in _pC>lic:yJIQMQXQ)

Politka __ ¡ _ ___ ---~!~~~ip_c!~~ _ allow execute

. allow write

, allow read

allow unlink

allow mkdir

! allow_nndir

• Esta palabra reservada concede penniso de ejecución en el pathname especificado. No se permiten comodines para pathname .

Esta palabra reservada concede al pathname especificado penniso para · abrir para leer.

Esta palabra reservada concede al pathname especificado penniso para abrir para leer y para escribir.

------ - -----

Esta palabra reservada concede que se pueda crear el pathname . especificado. ,· -· ·-· - ------------- - .

! Esta palabra reservada concede que se pueda eliminar el pathname i especificado. -+- --· ---- . ----------' Esta palabra reservada concede que se pueda crear el pathname especificado. El pathname debe ser un directorio.

: Esta palabra reservada concede que se pueda eliminar el pathname '.especificado. El pat~n_ame debe ser un directorio.

46

Jabla~._Qi~~ctivas de cont}~ración d~Lllrchiyo_gomain_policy (TQMOYQ)_.

i--allow mkfifo

allow mksock

allow mkblock

allow mkchar

allow truncate

allow _ symlink

allow link

allow rename

'allow rewrite

. use profile i -

Descripción

Esta palabra reservada concede que se pueda crear el FIFO especificado por el pathname.

Esta palabra reservada concede que se pueda crear el FIFO especificado , por el pathname.

. Esta palabra reservada concede que se pueda crear el dispositivo de • bloque especificado por el pathname.

Esta palabra reservada concede que se pueda crear el dispositivo de tipo 'caracter especificado por el pathname.

, Esta palabra reservada permite que el pathname especificado sea ! truncado o extendido.

i Esta palabra reservada concede que se pueda crearla liga simbólica en el pathname especificado.

• Esta palabra reservada concede que se pueda crearla liga de tipo hard en el pathname especificado.

Esta palabra reservada concede que se pueda renombrar el pathname . especificado.

Esta palabra reservada concede que se pueda reescribir el pathname especificado.

Esta palabra reservada cindica el número de perfil asignado a este [domin.io.

4.8.3 EXCEPCIONES CAO SOPORTADAS EN LOS HUÉSPEDES VIRTUALES

En la tabla 6 se muestran las excepciones CAO soportadas en los huéspedes virtuales.

Tabla 6. Directivas de configuración del archivo exception__policy (TOMOYO)

allow read

id . ¡ eny_rewnte

Alias

Para conceder permisos de lectura incondicional, se emplea la palabra reservada · seguida del nombre de archivo.

-- -- --

' Para evitar de reescritura de archivos de contenido (tal como archivos de bitácora) , emplearla palabra reservada seguida del nombre de archivo.

- ---

: Pennite la ejecución de programas empleando el nombre de ligas simbólicas . Emplear ' la palabra reservada seguido por el pathname referenciado. Este palabra reservada tiene el objetivo de permitir que los programas se comporten de fonna diferente dependiendo · del nombre de invocación y la referencia utilizando ligas simbólicas en vez de hard

'Iinks.

47

5. IMPLEMENTACIÓN DE LA ARQUITECTURA

VMWare Server 2.0 es la platafom1a de virtualización utilizadas para la implementación de la arquitectura. Dicha plataforma está instalada en un servidor fisico que tiene instalado Ubuntu Server 8.1 O x64. En la plataforma de virtualización se crearon tres máquinas virtuales con Ubunto Desktop 10.04 . Una de las máquinas virtuales (tomo03) será utilizadas como nodo maestro y dos máquinas virtuales (tomoOl y tomo02) serán utilizadas como huéspedes virtuales. En el nodo maestro se instaló el servidor de base de datos MySQL server, en dicho manejador se creo la base de datos "cao" (utilizada por el repositorio de políticas CAO).

En el nodo maestro se generó la llave privada y llave publica en formato PEM, la llave privada es utilizada para fim1ar digitalmente archivos; mientras que la llave publica es utilizada para verificar que cierto mensaje fue realmente firmado por una de las partes.

En cada uno de los huéspedes virtuales se encuentra en ejecución el proceso vmciCao, dicho proceso se encuentra en ejecución en un ciclo infinito. El binario vmciCao se invoca con los argumentos -s y -p <PUERTO> para indicar que se trata de un servicio de tipo servidor (SOP) y que estará recibiendo conexiones en el puerto especificado. Previo a que el servicio de SOP pueda recibir políticas CAO se valida al servicio STP, dicha validación se logra mediante la generación de un challenge number el cual debe ser firmado con la llave privada de nodo maestro.

En el nodo maestro se encuentra en ejecución el proceso vmciCao. El binario vmciCao se invoca con los argumentos -c y -p <PUERTO> para indicar que se trata de un servicio de tipo cliente (STP). Este proceso se invoca durante las ventanas de tiempo especificadas dentro de la configuración del repositorio CAO. El nodo maestro es el que se encarga de iniciar el proceso de transmisión de políticas CAO hacía los nodos virtuales, las políticas son leídas del repositorio CAO (base de datos MySQL) y transmitidas a los nodos virtuales.

Todas y cada una de las políticas trasmitidas a cada uno de los huéspedes virtuales son verificadas mediante un digerido SHA256 para garantizar la integridad de las políticas transmitidas.

Una vez que el huésped virtual recibe todas las políticas CAO se procede a aplicar dichas políticas en el dominio de TOMOYO.

48

5.1 CONSTANTES Y VARIABLES GLOBALES

En el código 1 se listan las constantes utilizadas. En el código 2 y código 3 se listan las variables globales utilizadas.

Código l . Constante_s // ################################ //CON 5 TAN TE 5 // ################################ #define BUFSIZE 4096 // Tamaño del buffer

#define INITSERVER 0 // Utilizado por protocolPos[][INITSERVER] // Para especificar posición dentro de // protocol[][] en donde inician las directivas // del servidor

#define ENDSERVER 1 // Utilizado por protocolPos[][ENDSERVER] // Para especificar posición dentro de // protocol[][l en donde terminan las // directivas del servidor

#define INITCLIENT 2 // Utilizado por protocolPos[J[INITCLIENT] // Para especificar posición dentro de // protocol[J[J en donde inician las directivas // del cliente

#define ENDCLIENT 3

#define PARG 0

#define PVAL 1

// Utilizado por protocolPos[J[ENDCLIENTJ // Para especificar posición dentro de // protocol[J[l en donde terminan las // directivas del cliente

// Utilizado por protocol[][J // para definir el tipo // de operación // e.g. transmit/receive

// Utilizado por protocol[][] // para definir el valor del //.elemento que será // transmitido/recibido

#define PENTRIES 100 // No. maximo de entradas // para el manejo del protocolo

49

Código 2. Varia_ples gl9bales,parte 1 unsigned int CID= 0; // Id de Vmware int PORT = 0; // Puerto utilizado int peer= 0; // Handler de socket struct hostent *hp; // Estructura del host

,char *host; // Nombre del host

char *protocol [PENTRIESJ[2]; // Empleado para definir el protocolo // protocol[J [PARG] -> transmit/receive // protocol[](PVAL] -> elemento a // transmitir/recibir

char *protCommands[PENTRIESJ; // Comandos disponibles // prot5et[0] = "sendcao"

int protocolPos[PENTRIES][4];

int pNdxProt = 0;

int pNdxCmd = 0;

// Posiciones del servidor/cliente // por comando // protocolPos[](INITSERVER] // protocolPos[][ENDSERVER] // protocolPos[][INITCLIENT] // protocolPos[)[ENDCLIENT]

// Indice p/insertar nuevas // entradas en protocol[J[J

// Indice p/insertar nuevas // entradas en protCommands[]

// ************************ // Declaraciones p/B.D. // ************************

MYSQL *conn; MYSQL_RES *result; MYSQL ROW row; int num_fields; int i;

// Conexión // Resultset // Representa un registro // No. de campos del registro // Entera auxiliar

// ******************************* // Declaraciones servidor CRON // *******************************

bool cron_serviced[100]; // Valor=l -> ya se atendió // Valor=0 -> aún no atendido

// Los siguientes tres arreglos son llenamos por // el método de arranque windowloader()

int eran server[100]; int cron-hour[100]; int cron=min[100];

// server id en el que se activará //Horade activación // Minuto de activación

50

1

Código} .:y_ariable1,_gl()bales,parte 2 int ndxCron = 0; // Indice p/insertar nuevas entradas

bool eran resetted = 0;

// de tipo CRON

// valor=0 -> aún no ha sido // reiniciado el CRON // valor=l -> ya fué reiniciado el CRON

// PARAMETROS QUE SERA LEIDOS DE LA BASE DE DATOS // Valor por defecto de los parámetros

int cronResetHour=23; int cronResetMin=59;

//Horade reinicio del CRON // Minuto de reinicio del CRON

char pemPath[BUFSIZE]; // Ruta en la que se pueden localizar /! las llaves pública y privada.

char pemPrivKeyPath[BUFSIZE]; // Ruta en la que se localiza la llave // privada en formato PEM.

char pemPubKeyPath[BUFSIZE]; // Ruta en la que se localiza la llave // pública en formato PEM

char pemPrivKeyName[BUFSIZE]; // Nombre de la llave privada en // formato PEM.

char pemPubKeyName[BUFSIZEJ; // Nombre de la llave pública en / / formato PEM.

5.2 MÉTODOS DE INICIALIZAClóN

Tanto el servicio STP así como servicio SOP en preparación a la ejecución del servicio invocan los siguientes métodos:

a) protlnitializer() b) windowLoader() c) readDbParams()

5.2.1 MÉTODO protlnitializerO

El método se ejecuta durante la fase de inicialización. El arreglo protocolPos[][] es utilizado para especificar la posiciones del protocolo utilizado por el servidor (STP) así como las posiciones del protocolo empleado por el cliente (SOP). Las constantes INITSERVER y ENDSERVER representan la posición inicial y la posición final para el protocolo del STP; mientras que INITCLIENT y ENDCLIEND representan la posición inicial y la posición final para el protocolo

5,1

del SOP. El código 4 muestra la parte I de la inicialización del protocolo y el código 5 muestra la parte 2.

Código 4~_ Inic_i~Jiz~ció11: <i_el protocolo, parte __ l ______ _ void protinitializer() { //Inicializarlos arreglos del protocolo

:protCommands[pNdxCmd] = "sendcao";

protocolPos[pNdxCmd][INITSERVER] protocolPos[pNdxCmd][ENDSERVER]

¡protocolPos[pNdxCmd][INITCLIENT] !protocolPos[pNdxCmd++][ENDCLIENT]

= = = =

0; 5; 6; 11;

// Posiciones del seridor(SOP), init:0, end:5 :protocol[pNdx][PARG] = "receive"; 'protocol[pNdx++][PVAL] = "sendcao";

protocol[pNdx][PARG) = "transmit"; ·protocol[pNdx++][PVAL] = "acksendcao";

protocol[pNdx][PARG] = "receive"; protocol[pNdx++)[PVAL] = "datainit" ;

protocol[pNdx] [PARG] = "receive"; protocol[pNdx++][PVAL] = "data";

protocol[pNdx][PARG] = "receive"; iprotocol[pNdx++][PVAL] = "dataend";

protocol[pNdx][PARG) = "transmit"; .protocol[pNdx++][PVAL] = "endtx"; :¡¡ Posiciones del cliente(STP), init:6, end:11 · protocol [pNdx] [PARG] = "transmit"; protocol[pNdx++][PVAL] = "sendcao";

protocol[pNdx][PARG] = "receive"; protocol[pNdx++][PVAL] = "acksendcao";

protocol[pNdx][PARG] = "transmit"; protocol[pNdx++][PVAL) = "datainit";

:protocol[pNdx][PARG] = "transmit"; protocol[pNdx++](PVAL] = "data";

,protocol[pNdx][PARG] = "transmit"; protocol[pNdx++][PVAL] = "dataend";

protocol[pNdx][PARG] = "receive"; 1

protocol[pNdx++][PVAL] = "endtx";

printf("Protocolo inicializado !\n");

}

52

El arreglo protocol[][] está compuesto por dos columnas, la columna P ARG y la columna PV AL. La columna P ARG es un elemento que puede tener el valor "transmit" o "receive" dependiendo de la operación requerida por los servicios. PV AL es el valor esperado en el caso de una operación "receive"; mientras que en el caso de una operación "transmit" representa el valor a ser transmitido al otro extremo de la conexión.

5.2.2 MÉTODO windowLoaderO

Durante la fase de arranque de la aplicación se ejecuta este método. El objetivo es el de poblar los arreglos cron_server[], cron_hour[], cron_min[] y cron_serviced[] a partir de los renglones almacenados en el objeto de base datos "windows".

Código 5.Jvtét_oci9 windg~l.-~ª-<!~rO void windowloader() {

// -init------db data-----//Recuperar las entradas del CRON a partir de la BD----------conn = dbConnect("localhost", "cao", "root", "test"); mysql query(conn,"SELECT server id, hour, min FROM cao.windows

where server_id = 100 order by 1,2,3");

}

// Obtener el resultset result = mysql_store_result(conn);

while ((row = mysql_fetch_row(result))) {

}

// row[0]=server id, row[l]=hour // y row[2]=min -cron serviced[ndx cron] =0; // aún no despachado cron-server[ndx cron] = atoi(row[0]); cron-hour[ndx cron] = atoi(row(l]); cron=min[ndx_cron++] = atoi(row[2]);

//Liberarlos recursos mysql_free_result(result); mysql_close(conn); // -end------db data---------------------------------------------

53

5.2.3 MÉTODO readDbParamsO

Durante la fase de arranque de la aplicación se ejecuta este método. Este método inicializa las variables globales cronResetHour, cronResetMin, pemPath, pemPrivKeyPath, pemPubKeyPath, pemPrivKeyName y pemPubKeyName. En la Tabla 4 se puede observar el uso de cada uno de los parámetros.

Tabla 7. Parámetros leídos de la .Base de Da tosen tiemJJQ de arranque

Parámetro

cronResetHour

Descripción

Hora en la que se reiniciará el CRON, mediante cronResetter().

cronResetMin · Minuto en el que se reiniciará el CRON, mediante cronResetter().

pemPath

pemPrivKeyPath

Ruta en la que se pueden localizar las llaves pública y privada.

Ruta en la que se localiza la llave privada en formato PEM.

Ruta en la que se localiza la llave pública en formato PEM.

Nombre de la llave privada en formato PEM.

--- - -- ----

pemPubKeyPath

• pemPrivKeyName -- ---- --------

pemPubKeyName Nombre de la llave pública en formato PEM.

El código 6 muestra el contenido del método readDbParams().

Código 6. Método readDbParams(), parte 1. void readDbParams() {

conn = dbConnect("localhost", "cao", "root", "test");

mysql_query(conn, "SELECT param_name, param_value FROM cao.parameters arder by param_name ase");

// Obtener resultset result = mysql store result(conn); while ((row = mysql_fetch_row(result))) { // row[l]=param name, row[l]=param value

if (strcmp( row[0], "cronResetHour") == 0) cronResetHour = atoi(row[l]);

else if (strcmp(row[0],"cronResetMin") == 0) cronResetMin = atoi(row[l]);

else if (strcmp( row[0], "pemPath") == 0) { cleanBuf(pemPath,200); strcpy(pemPath,row[l]); printf("pemPath: %s\n",pemPath);

} else if (strcmp(row[0],"pemPrivKeyPath") == 0) {

cleanBuf(pemPrivKeyPath,200); strcpy(pemPrivKeyPath,row[l]); printf("pemPrivKeyPath: %s\n",pemPrivKeyPath);

}

54

Código] .. 1\1.~todo readDbParamsO, parte i

}

else if (strcmp(row[0],"pemPubKeyPath") == 0) { cleanBuf(pemPubKeyPath,200); strcpy(pemPubKeyPath,row[l]); printf("pemPubKeyPath: %s\n",pemPubKeyPath);

} else if (strcmp(row[e],"pemPrivKeyName") == e) {

cleanBuf(pemPrivKeyName,2ee); strcpy(pemPrivKeyName,row[l]); printf("pemPrivKeyName: %s\n",pemPrivKeyName);

} else if (strcmp(row[e],"pemPubKeyName") == e) {

cleanBuf(pemPubKeyName,200); strcpy(pemPubKeyName,row[l]); printf("pemPubKeyName: %s\n",pemPubKeyName);

} } // end while, fetch db data //Liberarlos recursos mysql_free_result(result); mysql_close(conn); printf("Parámetros leídos de la B.O. \n");

5.3 SERVICIO DE PLANIFICACióN

Este servicio se inicia en tiempo de arranque del master nade y se encuentra en ejecución en un ciclo infinito. El servicio de Planificación se encarga de agendar la transmisión de políticas CAO al servicio STP.

El servicio de Planificación está integrado por los siguientes métodos: a) void windowLoader() b) char * activeServer( char * ipAddress) c) void updateActiveServers() d) bool cronMatcher(int pHour, int pMin)

La estructura del servicio de planificación se muestra en el Código 8.

55

Código S._ Servicio de Planificación

void main( ... ) {

windowLoade r ( ) ;

while ( 1) {

while (1) {

if ( cronMatcher(tmPtr->tm_hour, tmPtr->tm_min) ) { updateActiveServers(); break;

}

} // end while interno

startStp();

} // end while externo

¡} // end main()

5.3.1 MÉTODO activeServersO

Este método emplea el comando "ping" para determinar si el servidor en la dirección "ipAddress" está activo. Se regresa el resultado "active" cuando responde como "64 bytes from localbost ( 127 .0.0.1 ): icmp _ seq= 1 ttl=64 time=0.099 ms", de otra manera regresa "inactive".

Código_~_. Método activeServersO char * activeServer(char * ipAddress) {

char pingCommand[BUFSIZE]; strcpy(pingCommand,"ping -e 1 "); strcat(pingCommand,ipAddress); strcat(pingCommand," 1 grep icmp_seq");

}

FILE· *cmdl=popen ( pingCommand, "r"); char result[BUFSIZE]={0x0}; while (fgets(result, sizeof(result), cmdl) !=NULL)

printf("%s", result); pe lose ( cmdl) ;

if (strstr(result,"icmp_seq") != NULL) return "active";

else return "inactive";

56

5.3.2 MÉTODO updateActiveServersO

Este método actualiza la columna "status" del objeto de base de datos servers con el valor regresado por el método activeServer(ipAddress). Todas las entradas de la tabla "servers" son actualizadas con el valor de estado correcto. Este método es invocado previo a la trasmisión de políticas CAO al hupesped virtual ( en el método startStp()).

En el código 1 O se muestra el código fuente del método updateActiveServers().

Código IQ. Método updateActiveServersQ void updateActiveServers() {

}

/! -init------db data---------------------------------------conn = dbConnect("localhost", "cao", "root", "test"); mysql_query(conn,

"SELECT id, hostname, ip FROM cao.servers arder by id ase");

// Get the resultset result = mysql store result(conn); // -end------db data~----------------------------------------

while ((row = mysql_fetch_row(result))) {

// row[B]=id, row[l]=hostname, row[2]=ip // Verificar estado char * estado; estado= active5erver(row[2]);

// Actualizar estado en DB

char tmpQuery[BUFSIZE]; strcpy(tmpQuery,"update cao.servers set status='"); strcat(tmpQuery,estado); strcat(tmpQuery,"' where id="); strcat(tmpQuery,row[0]); mysql_query(conn, tmpQuery); printf("Update executed: %s\n",tmpQuery);

} // end while, fetch db data

// Liberar recursos mysql_free_result(result); mysql_close(conn); printf("updateActiveServers realizado \n");

5.3.3 MÉTODO bool cronMatcher(int pHour, int pMin)

Este método regresa verdadero sí ambos parámetros pHour y pMin coinciden con las entradas de los arreglo cron _ hour[] y cron _ min[]. A parte de que coincidan las entradas se valida también que

57

la petición no haya sido atendida (para que no haya sido atendida el arreglo cron _ serviced[] en la posición dada deberá tener un "O", de lo contrario será indicativo de que ya fue despachado el servicio).

Dentro de este método se realiza el reinicio del CRON ( el reinicio consiste en limpiar el arreglo cron_serviced[], poniendo todas sus entradas en cero) cuando la hora del sistema coincide con los parámetros globales cronResetHour y cronResetMin; mismos que están definidos dentro del objeto parameters del repositorio CAO. El reinicio del CRON se realiza solamente una vez al día. Mediante la variable booleana global cron _resseted se controla que el reinicio del CRON se realice una sola vez. Inicialmente la variable cron _resetted está inicializada en false (O). El código 1 O muestra el código fuente del método cronMatcher().

Código 11. Método cronMatchei:_Q bool cronMatcher(int pHour, int pMin) {

int i=El; bool matched = 0; //falso printf("%d: :%d\n" ,pHour,pMin);

// Reseteo del CRON

if (! eran resetted &&

}

pHour == cronResetHour && pMin -- cronResetMin) { cronResetter(); printf("Resetting CRON .... ");

// auxiliar para el reinicio del CRON

if (cron_resetted &&

}

pHour == cronResetHour && pMin == (cronResetHour+l) ) {

eran resetted=0; printf ( "Re-enable reset .... ");

// CRON matcher

far (i=B; i<ndx eran; ++i) { printf("Cron-serviced: %d\n",cron_serviced[i]);

if (cron_hour[i] == pHour && eran min[i] == pMin && cron_serviced[i]==0)

{

}

matched = 1; eran serviced[i]=l; prin¡f("Match %d:%d\n",cron_hour[i],cron_min[i]); break;

} // end if interno

return matched; } // end cronMatcher

58

5.3.4 CICLO INFINITO DE EJECUCIÓN

Mediante el ciclo infinito se agenda la transmisión de políticas CAO durante las ventanas de servicio. Sí la hora actual del sistema coincide con la hora definida por las ventanas de servicio (la coincidencia de la hora actual del sistema con la hora definida por las ventanas de servicio se valida mediante la invocación al método cronMatcher()) se iniciará el proceso de transmisión de políticas CAO al huésped virtual mediante el método startStp(). Previo a la invocación del método startStp() se invoca el método updateActiveServers(), de tal manera que solamente se transmitan las políticas CAO a los servidores activos en ese momento.

Código 12. Ciclo infinito de ejecución

while (1) { // ***** while infinito***********************

// Implementación del CRON

printf( "Esperando la siguiente ventana de servicio ... \n");

while ( 1) {

//Obtenerla hora actual

tiempo= time(NULL); tmPtr = localtime(&tiempo); strftime( format time, 80,

"%H:%M.%S,-%A de %8 de %Y", tmPtr ); sleep(S);

if ( cronMatcher(tmPtr->tm_hour, tmPtr->tm_min) ) { // update Active Servers updateActiveServers(); break;

}

} // end while interno

// Iniciar con el proceso de TX de políticas CAO startStp();

} // **** end while infinito**************

59

5.4 SERVICIO STP

Este servicio se ejecuta en el huésped virtual administrativo cada vez que se activa el CRON. El método startStp() implementa la lógica del servicio. El servicio consta de los siguientes bloques de código:

a) Crear socket en el huésped virtual administrativo. b) Conectar socket del STP al huésped virtual. c) Consulta del repositorio CAO para la obtención de políticas. d) Manejo del protocolo a nivel STP

5.4.1 a) CREAR SOCKET EN EL HUÉSPED VIRTUAL ADMINISTRATIVO (STP)

El Código 12 muestra como crear el socket en el huésped virtual adn1inistrativo.

Código 13. Blogue para crear socket en el huésped v_i_rtual administrativo void startStp()

{ int sockfd;

// dirección socket del huésped virtual

struct sockaddr in server; char sendBuf[BUFSIZE], recBuf[BUFSIZE];

/*llenarla estructura de direcciones con la información del huésped virtual con el que se conectará */

server.sin family = AF INET; server.sin-addr.s addr-=

- - (((struct in addr *) (hp->h addr))->s addr); server.sin_port = htons(PORT); - - -

printf("- Creando el socket en (STP) \n"); sockfd = getSocketHandle(SOCK_STREAM, 0);

5.4.2 b) CONECTAR SOCKET DEL STP AL HUÉSPED VIRTUAL

El Código 14 muestra como conectar el socket del huésped virtual administrativo (STP) al huésped virtual.

60

Código 14. Conectar socket del STP al hué~peci_yjrtual

printf("- Conectando el socket al huésped virtual (SOP)\n");

/* conectandose al PUERTO en el Huésped Virtual*/

if (connect(sockfd, (struct sockaddr *)&server,

}

· sizeof(server)) == -1) { perror("Error de Conexión al huésped virtual !"); exit (1);

5.4.3 e) CONSULTA DEL REPOSITORIO CAO PARA LA OBTENCION DE POLÍTICAS

El Código 15 muestra el código fuente para consultar el repositorio CAO para la obtención de políticas.

Código 15. Consulta_ del _re.IJositorio CAO piffii la obtención depoHticas __________________________ . // -init------db data---------------------------------------conn = dbConnect("localhost", "cao", "root", "test"); mysql_query(conn, "SELECT kernel_id, policy_sec, policy_val FROM

cao.kernel_policies where kernel_id = 1 order by policy_sec ase");

// Get the resultset result = mysql_store_result(conn); // -end------db data----------------------------------------

//Obtenerlas políticas CAO // row[0]=primer columna, row[l]=segunda columna

5.4.4 d) MANEJO DEL PROTOCOLO A NIVEL STP

En la etapa de manejo de protocolo se realiza los siguientes pasos: d. l) Inicialización de variables para el manejo del protocolo. d.2) Manejo del protocolo a nivel STP.

5.4.5 d.1) INICIALIZACióN DE VARIABLES PARA EL MANEJO DEL PROTOCOLO

En el código 16 se definen las variables que se utilizan para el manejo del protocolo. Tanto recBytes como sentBytes se emplean para llevar el control del número de bytes que fuerón transmitidos y el número de bytes que fueron recibidos por el servicio de STP.

61

Código t6. lnicializaci~n de variables para el manejo delJ)_rotocolo // Preparación de variables para manejo del protocol

int recBytes = 0; int sentBytes = 0; int finder = -1;

bool valid = 0;

// Apuntar al arreglo protocolPos // para determinar posiciones de // directivas del protocolo tanto // para el servidor como para // el cliente. // Un valor de -1 implica que no // encontró el servicio

// falso

int protocolinitPos = 0; //Apuntadora la pos1c1on en donde // inician las directivas STP (cliente) // en el arreglo protocol[][]

char txChallenge[BUFSIZE]; // digest firmado con la llave privada

// Obtención de apuntador dentro del arreglo // protocolPos finder = protFinder("sendcao");

5.4.6 d.2) MANEJO DEL PROTOCOLO A NIVEL STP

En el código 17 se muestra el código fuente para el manejo del protocolo a nivel STP.

62

Códig_o ! 7 ,Map.ejo delpr2tocolo a_11ivel STf>,_part_eJ

if (finder != -1) {

// Posición inicial del protocolo cliente protocolinitPos = protocolPos[finder][INITCLIENT]; strcpy(sendBuf,protocol[protocolinitPos][PVAL]);

while ( 1) { // ************************************** // enviar datos, calcular SHA2 // ************************************** //#############inicia if para PVAL="data" ############ if ( strcmp(protocol[protocoUnitPos][PVAL],"data") == 9

{ // enviar datos de la base de datos // transmitir policy_val al huésped virtual // protocol[][PVAL] // TX INFO B.D. AL HUÉSPED VIRTUAL sendData(sockfd, sendBuf, strlen(sendBuf), 9);

// calcular SHA2 del send buffer sha256send = sha2(sendBuf);

// esperar recepción del SHA256 !/ enviado por el HUÉSPED VIRTUAL recBytes=receiveData(sockfd, recBuf, BUFSIZE, 9):

// obtener SHA256 del huésped virtual // para compararlo vs. el SHA256 calculado sha256rec = recBuf;

// Validar que el SHA2 transmitido // y recibidos son iguales

if (strcmp(sha256send, sha256rec) == 9) printf("SHA2 paso la prueba ... \n");

else { printf("SHA2 fallo ... \n"); exit(-1); // detener ejecución }

// Posicionarse en la siguiente directiva ++protocolinitPos;

// Preparar sendBuf con policy_value strcpy(sendBuf,protocol[protocolinitPos][PVAL]);

} //########## end if para PVAL="data" ##########

63

Código 18 .Manejo del protocolo a nivel STP, parte 2 1 -- --

0);

else { //#########inicia else para PVAL="data" ####### // Posicionarse en la siguiente directiva // del protocolo protocotinitPos++;

// verificar si se trata de datainit // de ser asi concatenar el Challenge // firmado con la llave privada y transmitirlo // al HUÉSPED VIRTUAL if ( strcmp(sendBuf,"datainit") == 9) {

strcat(sendBuf,txchattenge); }

sentBytes=sendData(sockfd, sendBuf, strlen(sendBuf),

} // ########### end else para PVAL="data" ##########

//#########solo para comandos de receive ############## if ( strcmp(protocot[protocotinitPos][PARGJ,

"receive") == 9) {

// Recibir datos enviados por SOP (server) recBytes=receiveData(sockfd, recBuf, BUFSIZE, 9);

// ******************************** // // // // if

}

Recibir e HALL EN GE number generado por el SOP (server)

viene en mensaje acksendcaoXXX ********************************

strstr(recBuf,"acksendcao") != NULL) {

// en recBuf queda el challenge number strcpy(buff,recBuf+19);

// txchallenge = challenge firmado con // llave priv. a TX a SOP (server) strcpy(txchattenge, chattengeProcessor(buff))¡

strcpy(recBuf,"acksendcao");

64

Código 19 .Manejo del protocolo a nivel STP, parte 3

// verificar endtx por parte de STP // para actualizar el status de la tabla server_policies if (strcmp(recBuf,"endtx") == 9) {

mysql_query(conn, "update cao.server_policies set status='applied' where kernel_id = 1");

} // end if endtx

// Validar que recBuf sea una directiva valida

// de tipo receive valid = protValidator(protocolinitPos,

"receive",recBuf); if (valid) { //####DIRECTIVA RX VALIDA####

// verificar si hay mas sentencias ++protocollnitPos; if ( protocollnitPos <=

protocolPos[finder][ENDCLIENT] ) { cleanBuf(sendBuf,BUFSIZE); strcpy(sendBuf,protocol[protocollnitPos][PVAL]); }

else break; // no hay mas sentencias a procesar } // end if valid

else { //####DIRECTIVA RX INVALIDA####

}

printf ( "Problemas con el protocolo de STP ! \n"); break;

} // ######### end if solo para comandos receive ########

} // end while (1)

} // end if finder != ·1

Previo a que el servicio SOP (server) acepte la recepción de políticas CAO se enviara un challenge al servicio STP en el mensaje TX acksendcao<CHALLENGE_NUMBER>. El servicio STP procesará el <CHALLENGE_NUMBER> mediante el método challengeProcessor(). El objetivo del método challengeProcessor() es la firma del <CHALLENGE_NUMBER> con la llave privada, el digerido generado es entonces transmitido de regreso al servicio SOP (server) en el mensaje TX datainit<SIGNED_CHALLENGE_NUMBER>. En el código 20 se muestra el código fuente del método challengeProcessor().

65

Código 20 .Método challengeProcessorO ·¡¡ ************************ // challenge processor // Firma con la llave privada // el challenge number enviado // por SOP {server) // ************************ char * challengeProcessor{char * pChallenge) {

// Almacenar localmente challenge number // challenge.txt

strcpy(buffChaUenge,"echo \""); strcat(buffChallenge,pChallenge); strcat(buffChaUenge,"\" > /tmp/chaUenge.txt")¡ system(buffChallenge)¡

// Firmar challenge number con // llave privada // Firmar challenge.txt con pem

strcpy{buffChallenge,"openssl dgst -sha256 -sign 11);

strcat(buffChallenge,pemPrivKeyPath); strcat{buffChallenge,"/"); strcat{buffChallenge,pemPrivKeyName); strcat{buffChallenge," ·out /tmp/challenge.sha256

/tmp/challenge.txt");

system(buffChallenge);

// ~onvertir a texto challenge.sha256 // para su transmisión

strcpy(buffChallenge,"uuencode /tmp/challenge.sha256 /dev/stdout > /tmp/challenge.uu");

}

system(buffChallenge);

// Regresar digerido {challenge firmado) FILE *cmdl=popen ( "cat /tmp/chaUenge. uu 11

, 11 r") ;

while (fgets(result, sizeof{result), cmdl) !=NULL) { strcat(totalResult,result)¡ }

pclose(cmdl);

resultado= totalResult¡ return resultado;

66

5.5 SERVICIO SOP

Este servicio está en ejecución en cada uno de los huéspedes virtuales que forman parte del dominio de administración. Se activa cuando recibe un mensaje RX sendcao por parte del huésped virtual administrativo (STP). El servicio consta de los siguientes bloques de código:

a) Crear socket en el huésped virtual (server). b) Procesar peticiones del servicio STP (cliente) c) Manejo del protocolo a nivel SOP

5.5.1 a) CREAR SOCKET EN EL HUÉSPED VIRTUAL (SOP)

La llamada listen() prepara al master node para recibir conexiones entrantes de los huésped virtuales. La macro BACKLOG predefine el número de conexiones que el sistema acepta antes de rechazar nuevas. Está función es la misma que listen() en aplicaciones regulares TCP.

El Código 21 muestra como crear el socket en el huésped virtual.

Código 21 . Crear socket en el huésped virtual (SOP)

printf("- Creando el socket en el huésped virtual (SOP)\n"); sockfd = getSocketHandle(SOCK_STREAM, 9);

printf("- Ligar socket a cualquier cliente\n"); if (PORT == 0 && CID== 0)

bindToAnyPort(sockfd); else if (PORT != 0)

bindToPort(sockfd, PORT);

printf("- Información local del socket ... \n"); if (printSocketinfor(sockfd))

salir();

printf("- Esperando al servicio STP ... \n\n"); printf("Proceso %d padre escuchando\n", getpid() );

/! ponerse a escuchar a través del socket if (listen(sockfd, 5) == -1) {

perror("listen"); exit(l);

}

67

5.5.2 b) PROCESAR PETICIONES DEL SERVICIO STP (CLIENTE)

La llamada accept() espera indefinidamente() a que lleguen las conexiones entrantes, creando un nuevo socket (y descriptor de stream) cuando llegue la conexión del huésped virtual. La estructura their addr se llena con información de la conexión.

El Código 22 muestra como procesar peticiones del servicio STP (cliente).

Código 22 .Procesar peticiones del servicio STP (cliente) while (1) {

/* esperando que STP solicite el servicio, no me interesa la dirección del cliente*/ if ( (peer= accept(sockfd, 9, 9)) == -1) {

perror("accept"); exit ( 1);

}

if ( fork 0==9) { FILE *file; // archivo que contiene las políticas CAO // a ser aplicadas, file.txt file= fopen("/tmp/file.txt","w");

// archivo que contiene el <CHALLENGE_NUHBER> firmado // por el servicio STP, challenge.signed FILE *fileDigest; fileDigest = fopen("/tmp/chaUenge.signed","w");

// tomar un mensaje del cliente

// Obtención de apuntador dentro del arreglo

// protocolPos finder = protFinder("sendcao");

// Posición inicial del protocolo SERVER protService = protocolPos[finder][INITSERVER]; posEndServer = protocolPos[finder][ENDSERVER];

// ######## init while receiveData() ################# while ((recBytes=receiveData(peer, buf, BUFSIZE, 9)) ) {

// Manejo del protocolo // a nivel SOP (server) // ver c) Manejo del protocolo a nivel SOP

} // ########### end while receiveData() ###############

68

5.5.3 e) MANEJO DEL PROTOCOLO A NIVEL SOP

El Código 23 muestra como crear el socket en el huésped virtual administrativo.

Código 23.Manejo del protocolo a nivel SOJl_,J~arte 1

// ######## init while receiveData() ##'11############## while ((recBytes=receiveData(peer, buf, BUFSIZE, 8)) ) {

// validar INIT de write en disco // Recuperar <CHALLENGE NUMBER> firmado // por el servicio STP -// viene en el mensaje // datainit<CHALLNGE_NUMBER_FIRMADO>

if (strstr(buf,"datainit") != NULL) {

// tmpbuff contiene el <CHALLENGE_NUMBER_FIRMADO> strcpy(tmpbuff,buf+8); printf("Signed digest: %s\n",tmpbuff);

// escribir a disco <CHALLENGE NUMBER FIRMADO> fprintf(fileDigest,"%s",tmpbuff); -fclose(fileDigest); // Cerrar archivo

// Restaurar archivo.SHA2 firmado sin uu system("uudecode -o /tmp/chaUenge.sha256.cmp

/tmp/chaUenge. signedll);

// *********************************** // VALIDAR QUE EL MENSAJE FUE FIRMADO // REALMENTE POR EL CLIENTE // VALIDA EL <CHALLENGE_NUMBER_FIRMADO> // ***********************************

strcpy(cmdValMensaje, "openssl dgst -sha256 -verify ");

strcat(cmdValMensaje,pemPubKeyPath); strcat(cmdValMensaje,"/"); strcat(cmdValMensaje,pemPubKeyName); strcat(cmdValMensaje," -signature

/tmp/challenge.sha256.cmp /tmp/challenge.txt");

69

Código 24.Ma.nejo del protocolo a nive_l ~01\ p::iI1e i FILE *cmdl=popen(cmdValMensaje, "r"); char verificarFirma[100]={0x0}; while (fgets(verificarFirma,

sizeof(verificarFirma), cmdl) !=NULL) printf("%s", verificarFirma);

pclose(cmdl); if ( strstr(verificarfirma,"Verified OK")

!= NULL) strcpy(buf, "datainit") :·

else { strcpy(buf,"dataerror"); printf("Signature verification failed ... \n"); break; }

// validar que la directa receive en "buf" sea valida

valid = protValidator(protocollnitPos,"receive",buf);

if (valid) { // ubicarse en el siguiente command ++protocolinitPos; if ( strcmp(buf,"datainit") == 9)

++protocollnitPos;

// validar que no este fuera de rango if (protocolinitPos > protocolEndPos) {

printf("Protocot error server ... \n"); break;

} } // ########### end if valid ############

else {

}

// datarx // envio de digest SHA2 durante data TX // Transmitir SHA2 de los datos recibidos

// Mediante sha2(buf) se calcula el SHA256 //delas políticas CAO recibidad printf("Bytes tx to client:%s -

%d\n",sha2(buf),sendData(peer,sha2(buf), strlen(sha2(buf)),9));

70

Código 25. Manejo del protocolo a nivel SOP, parte 3

}

// ######### init --transmit ################ if (strcmp(protocot[protocotinitPos)[PARGJ,

"transmit") == 0) { // Enviar TX respuesta // Sí se trata de acksendcao enviar // CHALLENGE number a STP

if strcmp(protocot[protocotinitPos][PVAL], "acksendcao") ==e) {

// preparación del CHALLENGE NUMBER // en la variable challenge queda // el CHALLENGE NUMBER

strcpy(chaUenge,"acksendcao"); strcat(chattenge,numero);

printf("Bytes tx to client: %d\n", sendData(peer,chattenge, strten(chattenge),O));

} // #### end if TX PVAL = acksendcao else

{ // TX protocot[][PVAL] printf("Bytes tx to client: %d\n", sendData(peer,

protocol[protocolinitPos][PVAL], strlen( · protocol[protocolinitPos][PVAL]),0));

}

// detectar endtx para Reseteo // Aplicación de políticas localmente // en el dominio de TOMOYO if (strcmp(protocot[protocotinitPos][PVAL],

"endtx") == 9) { protocotinitPos = 9; // Aplicar políticas apptyTomoyoPoticies();

break;

// pasar al siguiente comando (RX) ++protocotinitPos;

} // ########### end if transmit .########### } // ########### end while receiveData() ###############

71

5.6 REPOSITORIO DE POLÍTICAS CAO

El repositorio de políticas CAO es implementado mediante una base de datos MySQL que se está ejecutando en el mismo equipo que el servicio STP. El repositorio está compuesto por los siguientes objetos de base de datos:

a) servers b) kemels c) kemel_policies d) server _polcies e) windows f) parameters

5.6.1 a) CREACIÓN DEL OBJETO servers

En el script l se detalla el script para crear el objeto de base de datos server.

Script 1. Creación del objeto se_l"\'ers CREATE TABLE 'cao' ,'servers' ( 'id' INT( 4) NOT NULL, 'hostname' VARCHAR( 20) NOT NULL, 'ip' VARCHAR( 20) NOT NULL, 'status' VARCHAR( 10) NOT NULL, 'os' VARCHAR( 20) NOT NULL, PRIMARY KEY ( 'id' ) ) ENGINE = InnoDB CHARACTER SET latinl COLLATE latinl swedish ci;

mysql> dese servers; +----------+-------------+------+-----+---------+-------+ I Field I Type I Null I Key I Default I Extra I +----------+-------------+------+-----+---------+-------+ I id int(4) NO PRI NULL I hostname I varchar(20) 1 NO I NULL I ip I varchar(20) 1 NO I NULL I status I varchar(10) 1 NO I NULL I os I varchar(20) 1 NO I NULL +----------+-------------+------+-----+---------+-------+

insert into cao.servers(id, hostname,ip,status,os) values (100, 'localhost', '127.0.0.1', 'active', 'ubuntu');

mysql> select * from servers; +-----+-----------+-----------+--------+--------+

1 1 id I hostname I ip I status I os +-----+-----------+-----------+--------+--------+ 1 100 1 localhost 1 127.0.0.1 1 active I ubuntu I

+-----+-----------+-----------+--------+--------+ 1 row in set (0.00 sec)

72

5.6.2 b) CREACIÓN DEL OBJETO kernels

En el script 2 se detalla el script para crear el objeto de base de datos kemels.

Script 2. Creació!l del objetC> kernels (REATE TABLE 'cao' .'kernels' ( 'id' INT( 8) NOT NULL, 'path' VARCHAR( 2eee) NOT NULL, PRIMARY KEY ( 'id' ) ) ENGINE = InnoDB CHARACTER SET latinl

mysql> dese kernels;

COLLATE latinl swedish ci;

+-------+---------------+------+-----+---------+-------+ I Field I Type I Null I Key I Default I Extra I

+-------+---------------+------+-----+---------+-------+ I id I int(8) 1 NO I PRI I NULL I path I varchar(2000) 1 NO 1 1 NULL +-------+---------------+------+-----+---------+-------+

insert into cao.kernels(id,path) values (l,"<kernel> /etc/init.d/rc /etc/init.d/apache2");

mysql> select * from kernels; +----+---------------------------------------------+ I id I path +----+---------------------------------------------+

1 1 <kernel> /etc/init.d/rc /etc/init.d/apache2 1

+----+---------------------------------------------+ 1 row in set (0.00 sec)

5.6.3 e) CREACIÓN DEL OBJETO kernel_policies

En el script 3,4 y 5 se detalla el procedimiento para crear el objeto de base de datos kernel _policies.

Script 3.(reación del ol:>jt:!JC> de bª~~cle date>s_ kell!t:!l__polici~s, parte l CREATE TABLE 'cao' .'kernel policies' ( 'kernel id' INT( 8) NOT NULL, 'policy=sec' INT( 8) NOT NULL, 'policy_val' VARCHAR( 2000) NOT NULL, PRIMARY KEY ( 'kernel id' , 'policy sec' ) ) ENGINE = InnoDB CHARACTER SET lat1nl COLLATE latinl swedish ci;

ALTER TABLE 'kernel_policies' ADD FOREIGN KEY 'kernel id' REFERENCES 'cao'. 'kernels' ( 'id'

1) ON DELETE CASCADE ON UPDATE CASCADE

73

Script 4. Creac_ió_n delobjeto de base de datos kemel_policies, parte 2

dese kernel_policies; +------------+---------------+------+-----+---------+-------+ I Field I Type I Null I Key I Default I Extra I

+------------+---------------+------+-----+---------+-------+ I kernel_id I int(8) 1 NO I PRI I NULL I policy_sec I int(8) 1 NO I PRI I NULL I policy_val I varchar(2000) 1 NO 1 1 NULL +------------+---------------+------+-----+---------+-------+

: insert into kernel_policies ( kernel_id, policy_sec, policy_val) values (1,0, '<kernel> /etc/init.d/rc /etc/init.d/apache2');

insert into kernel policies(kernel id, policy_sec, policy_val) values ( l, l, 1 use_profile 3'); -

insert into kernel_policies(kernel_id, policy_sec, policy_val) values (1,2, 'allow_execute /usr/bin/env');

insert into kernel policies(kernel id, policy sec, policy_val) values (1,3, 'allow=execute /usr/bin/expr'); -

insert into kernel_policies(kernel_id, policy_sec, policy_val) values (1,4, 'allow_execute /usr/bin/tput');

insert into kernel policies(kernel id, policy_sec, policy_val) 'values (1,5, 'allow=read /bin/dash');

: insert into kernel_policies ( kernel_id, policy_sec, policy_val) ,values (1,6, 'allow_read /etc/apache2/envvars');

insert into kernel policies(kernel id, policy sec, policy_val) values (1,7, 'allow=read /etc/default/apache2');

insert into kernel_policies(kernel_id, policy_sec, policy_val) values (1,8, 'allow_read /etc/default/rcS');

insert into kernel_policies(kernel_id, policy_sec, policy_val) values (1,9, 'allow_read /etc/init.d/apache2');

insert into kernel_policies(kernel_id, policy_sec, policy_val) values (1,10, 'allow_read /etc/lsb-base-logging.sh');

insert into kernel_policies(kernel_id, policy_sec, policy_val) values (1,11, 'allow_read /lib/lsb/init-functions' );

insert into kernel policies(kernel id, policy sec, policy_val) values (1,12, 'allow_truncate /dev/null' ); -

74

1Sc:rjpt 5 ._C:_!~ac:ión_4el ()_lJj_e_t() _~ ºase_de_ d1:1t_2~ k~i:t1~l_p()licj es, p_arte }_ _ insert into kernel policies(kernel id, policy sec, policy val) values (1,13, 'allow write /dev/null'); - -

! -

¡mysql> select * from kernel_policies; +-----------+--------------------------------------------------------+

: 1 kernel_id I policy_sec I policy_val +-----------+----------+---------------------------------------------+

1 1 : 1

1

1

1 ¡ 1 1 1

<kernel> /etc/init.d/rc /etc/init.d/apache2 use_profile 3 allow execute /usr/bin/env allow=execute /usr/bin/expr allow_execute /usr/bin/tput allow read /bin/dash

1

i I 1

'1 : 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1

e 1 2 3 4 5 6 7 8 9

10 11 12 13

allow-read /etc/apache2/envvars allow=read /etc/default/apache2 allow read /etc/default/rcS allow=read /etc/init.d/apache2 allow_read /etc/lsb-base-logging.sh allow read /lib/lsb/init-functions allow-truncate /dev/null allow=write /dev/null

1

'1 1 +-----------+---------- ---------------------------------------------+

5.6.4 d) CREACIÓN DEL OBJETO server_policies

En el script 6 y 7 detallan el procedimiento para crear el objeto de base de datos server_policies.

Script 6.__<:reac:ió_11 del obj~t()_ de b_ªse de cl_ªtos ~~ry-~r _p()lici~~. part~I _ CREATE TABLE 'cao' .·server_policies' ( 'server id' INT( 4) NOT NULL, 'kernel-id' INT( 8) NOT NULL,

i'status' VARCHAR( 20) NOT NULL, 1

PRIMARY KEY ( 'server id' , 'kernel id' ) . ) ENGINE = InnoDB CHARACTER SET latinl COLLATE latinl swedish ci;

ALTER TABLE 'server_policies' ADD FOREIGN KEY ( 'server id' REFERENCES 'cao'.'servers' ('id' ) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE 'server_policies' ADD FOREIGN KEY ( 'kernel id' REFERENCES 'cao' .'kernels' ('id' ) ON DELETE CASCADE ON UPDATE CASCADE

75

~cript7_: Creacjón dele>_bjeto de base9:e_ datos __ !ierver_pplicies, parte L 1

dese server_policies; +-----------+-------------+------+-----+---------+-------+

¡ 1 Field I Type I Null I Key I Default I Extra I +-----------+-------------+------+-----+---------+-------+

. 1 server_id I int(4) 1 NO I PRI I NULL ¡ 1 kernel_id I int (8) 1 NO I PRI I NULL • 1 status I varchar(20) 1 NO 1 1 NULL +-----------+-------------+------+-----+---------+-------+

1 insert into server_policies(server_id, kernel_id, status) values (100,l, 'pending');

mysql> select * from server_policies; +-----------+-----------+---------+ I server_id I kernel_id I status +-----------+-----------+---------+

100 1 1 1 applied I

+-----------+-----------+---------+ 1 row in set (0.00 sec)

5.6.5 e) CREACIÓN DEL OBJETO windows

Los scripts 8 y 9 detallan el procedimiento para crear el objeto de base de datos windows.

~cripJI Cr~ación d~L_o_bjet<J_ci~ b~~_cle_d_!l.t_o~_\Vi!).d<J~§1 pafte 1 i CREATE TABLE 'cao' . 'windows' ( i'server id' INT( 4) NOT NULL, 'hour' INT( 2) NOT NULL, 'min' INT( 2) NOT NULL,

:PRIMARY KEY ( 'server id' , 'hour' , 'min' ) . ) ENGINE = InnoDB CHARACTER SET latinl COLLATE latinl swedish ci;

ALTER TABLE 'windows' ADD FOREIGN KEY server id' ) REFERENCES '' ca o ' ' servers ('id' ) ON DELETE CASCADE ON UPDATE CASCADE

insert into windows(server id, hour, min) values (100, 11,30 ) ; insert into windows(server=id, hour, min) values (100, 11,29 ) ;

. insert into windows(server id, hour, min) values (100, 18,36 ) ; ! insert into windows(server=id, hour, min) values (100, 18,41 ) ; 'insert into windows(server id, hour, min) values (100, 18,42 ) ; insert into windows(server=id, hour, min) values (100, 23,14 ) ;

76

Script 9. Crea_c_i§p del obj~to <Ít! l:,ª-st: de datoL""'i11dows, parte 2 :mysql> select * from windows; 1

+--------~--+------+-----+ I server_id I hour I min I +-----------+------+-----+ 1 100 1 11 29 1 100 1 11 30 1 100 1 18 36 1 100 1 18 41 1 100 1 18 42 1 100 1 23 14 +-----------+------+-----+ 6 rows in set (0.00 sec)

5.6.6 d) CREACIÓN DEL OBJETO parameters

Los scripts 10 y 11 detallan el procedimiento para crear el objeto de base de datos parameters.

Script _l O. __ r~-~~c;i_gn del ()1:,j~!º-~~ !J~~e_ d~_4ª!()_s_paramet~~~. paI't:~J (REATE TABLE 'cao' .'parameters' (

·'param_name' VARCHAR( 20) NOT NULL, 'param_value' VARCHAR( 100) NOT NULL, PRIMARY KEY ( 'param_name' )

. ) ENGINE = InnoDB CHARACTER SET latinl COLLATE latinl swedish ci;

¡insert into cao.parameters(param_name, param_value) :values('cronResetHour' ,'23');

i

insert into cao.parameters(param name, param_value) values('cronResetMin', '59'); -

insert into cao.parameters(param_name, param_value) values('pemPath', '/home/mgarcia/mgarcia/mtr/sem_4/tesisII/vmware/mysql_ C/digest');

insert into cao.parameters(param_name, param_value) values('pemPrivKeyName', 'mgkey.pem');

.insert into cao.parameters(param_name, param value) values('pemPubKeyName', 'mgarcia.pem');

insert into cao.parameters(param_name, param_value) values('pemPrivKeyPath', '/home/mgarcia/mgarcia/mtr/sem_4/tesis!I/vmware /mysql_C/digest');

:insert into cao.parameters(param_name, param_value) 'values('pemPubKeyPath', '/home/mgarcia/mgarcia/mtr/sem 4/tesisII/vmware/ !mysql_C/digest'); - '

77

Script 11. ():eación del objeto de bas~ et~ datos parameters, pa!te 2 'mysql> select * from parameters;

+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ I param_name I param_value +- -- - -- - - - - --- - --+- -- - - - - - - - - - - --- - - - - ---- - -- - - - - -- -,- --- - - - -- -- - - - - - -- - - - -- -- - - - -+

, 1 cronResetHour · 1 cronResetMin : 1 pemPath · 1 pemPrivKeyName I pemPrivKeyPath I pemPubKeyName I pemPubKeyPath

23 59 /home/mgarcia/mgarcia/mtr/sem_4/tesisII/vmware/mysql_C/digest mgkey.pem /home/mgarcia/mgarcia/mtr/sem_4/tesisII/vmware/mysql_C/digest mga reía. pem /home/mgarcia/mgarcia/mtr/sem_4/tesisII/vmware/mysql_C/digest

+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ 7 rows in set (0.00 sec)

5.7 CANAL DE ALTA VELOCIDAD

El canal de alta velocidad se implementa mediante VMCI sockets. Mediante los sockets de VMCI se logra la comunicación entre el servicio STP (que está en ejecución en el huésped virtual administrativo) y el servicio SOP ( que está en ejecución en los huéspedes virtuales, en donde se aplicarán las políticas TOMOYO).

Los métodos que forman parte del canal de velocidad son los siguientes:

a) getSocketHandle() b) printSocketlnfo() c) bindToAnyPort() d) bindToPort() e) receiveData() f) sendData()

5.7.1 a) MÉTODO getSocketHaodle()

Código 26_}1étodo getSocketHandle() ,// ************************ // getSocketHandle() // ************************ int getSocketHandle(int type, int reserved) {

}

int sockfd == -1; int afVHCI = VHCISock_GetAFValue();

if ((sockfd = socket(afVHCI, type, reserved)) == -1) {

}

showError("No pudo crear el socket"); salir();

return sockfd;

78

5.7.2 b) MÉTODO printSocketlnfoQ

,Código27 . .tvlétodo1:>ri_I1_tS_oclcet_InfoQ // ************************ // printSocketinfo() // ************************ int printSocketinfo(int sockfd) {

}

struct sockaddr_vm my_addr = {8}; int svm_size = sizeof(my_addr);

if (getsockname(sockfd, (struct sockaddr *) &my_addr, &svm_size) -- -1)

{

}

showError("No pudo recuperar el sockname local"); return -1;

printf(" * Local CID: %u\n * Local port: %u\n", my_addr.svm_cid, my_addr.svm_port);

return e;

5.7.3 e) MÉTODO bindToAnyPort()

La llamada a bind() asocia al stream socket con los settings de red en la estructura sockaddr _ vmstructure, en vez de la estructura sockaddr _ in.

La estructura sockaddr_vm contiene un elemento para context ID (CID), el cual especifica la máquina virtual. Para el huésped virtual esto es el CID local. Para el master node (listener), esto podría ser cualquier huésped virtual que se está conectando. Tanto VMADDR_CID_ANY como VMADDR_PORT_ANY están predefinidos de tal forma que en tiempo de bind o de conexión, el CID y puerto apropiado sean llenados a partir del huésped virtual. VMADDR _CID_ ANY es reemplazado con el CID de la máquina virtual y VMADDR_PORT_ANY proporciona un puerto del rango no reservado (>=1024).

El huésped virtual ( conector) puede obtener su CID local llamando VMCISock _ GetLocalCID().

La función bind() es la misma que se utiliza en aplicaciones tradicionales de TCP sockets.

En el código 28 se muestra el código fuente del método bindToAnyPort.

79

Código 28 .Método bindToAnyJ>ortQ // ************************************************** // bindToAnyPort{) // Utilizar CUALQUIER PUERTO disponible // Asociar el stream socket con los settings de red // en la estructura sockaddr vmstructure, // en vez de la estructura sockaddr in. // ************************************************** void bindToAnyPort{int sockfd) {

}

struct sockaddr vm my_addr = {0};

my_addr.svm_family = VMCISock_GetAFValue(); my_addr.svm_cid = VMADDR_CID_ANY; my_addr.svm_port = VMADDR_PORT_ANY¡

if {bind(sockfd, (struct sockaddr *) &my_addr, sizeof(my_addr)) -- -1)

{

}

showError{"NO pudo asociar el socket."); salir{);

5.7.4 d) MÉTODO bindToPortO

Código 29 .Método bintToPort() // ************************************************** // bindToPort{), utilizar el PORT especificado // Asociar el stream socket con los settings de red // ************************************************** void bindToPort(int sockfd, int port) {

} }

struct sockaddr_vm my_addr = {0}; my_addr.svm_family = VMCISock_GetAFValue()¡ my_addr.svm_cid = VMADDR_CID_ANY¡ my_addr.svm_port = port¡

if (bind(sockfd, (struct sockaddr *) &my_addr, sizeof(my_addr)) -- -1)

{ showError{"No pudo asociar el socket."); salir{);

80

5.7.5 e) MÉTODO receiveDataQ

La llamada recv() lee los datos . Los nodos pueden comunicar la longitud de los datos transmitidos.

Códig() 39 .Método_receivep~_taO, parteL__ _ // ************************ // receiveData() // ************************

int receiveData(int sockfd, char* buf, int bufSize, int reserved) {

int bytesReceived = 0; struct sockaddr_vm their_addr = {0}; int svm_size = sizeof(their_addr);

if ((bytesReceived = recvfrom(sockfd, buf, bufSize * sizeof(char), reserved,

(struct sockaddr *) &their_addr, &svm_size)) -- -1) showError("Error, recvfrom. ");

printf("[SOCKET-receivefrom] Bytes recibidos: %d\n", bytesReceived);

int ndx = 0; for (ndx=0; ndx < bytesReceived; ++ndx) {

if (buf[ndx] == '\0')

buf[ndx] = '\n';

}

return bytesReceived;

5.7.6 t) MÉTODO sendDataO

81

Código 31 .Método sendDataQ // ************************ // sendData() // ************************ int sendData(int sockfd, char* buf, int bufSize, int reserved) {

}

int bytesSent = 0; struct sockaddr vm their addr = {0};

their addr.svm family = VMCISock GetAFValue(); their-addr.svm-cid = CID; -their=addr.svm=port = PORT;

if ((bytesSent = sendto(sockfd, buf, bufSize, reserved, ( struct sockaddr *) &their addr, sizeof(their_addr))) == -1)

showError("Error, sendto."); printf("[SOCKET-sendTo] Bytes sent: %d\n",bytesSent);

return bytesSent;

5.8 PROTOCOLO DE COMUNICACIÓN

El protocolo de comunicación que se utiliza entre los huéspedes virtuales y huésped virtual administrativo se define con base en la siguiente tabla. El protocolo está implementado tanto en el sevicio STP así como en el servicio SOP, con los metodos startStp() y starSop respectivamente.

Ta~la _8. Prot()colo de co_mu_nicación entl"e ~l ~~ryi<::iQ_!ffJ> y el servicio SOP Comando (SOP) . Directiva (SOP) Comando (STP) Directiva (STP)

Receive Sendcao Transmit Sendcao

Trasmit acksendCao<CHALLENGE N Receive acksendcao<CHALLENGE NU UMBER> MBER>

----·-···--------

Receive Datainit<CHALLENGE NUM Transmit Datainit<CHALLENGE NUMB BER FIRMADO> ER FIRMADO>

Receive Data Transmit Data

Receive Dataend Trasmit Dataend

Transmit Endtx Receive endtx ------ - ------------ - . •···-- -----··

El mensaje Sendcao es utilizado para señalizar al servicio SOP el inicio de la transmisión de políticas CAO desde el servicio STP.

El serv1c10 SOP responde al mensaje sendcao con el mensaje acksendcao<CHALLENGE_NUMBER>. El mensaje de acknowledge va sobrecargado con un número aleatorio generado por el servicio SOP (CHALLENGE_NUMBER).

82

Una vez que el servicio STP recibe el CHALLENGE_NUMBER enviado por el servicio SOP, procede a firmarlo con su llave privada (para autenticarse ante el servicio SOP). Una vez firmado el CHALLENGE_NOMBER, se realiza el envio del mensaje datainit<CHALLENGE NUMBER FIRMADO> al servicio SOP. - -

El servicio SOP recibe el CHALLENGE_NUMBER_FIRMADO en el mensaje sobrecargado datainit. Una vez que se tiene el digerido, el servicio SOP valida si el CHALLENGE_NUMBER fue firmado realmente por el servicio STP, de ser así se procede a la recepción de políticas CAO.

Las políticas CAO son enviadas después de haber recibido el mensaje data en el servicio SOP.

El mensaje dataend recibido en el servicio SOP es indicativo de que ya fueron trasmitidas todas las políticas CAO desde el servicio STP.

Como confinnación del mensaje dataend, el servicio SOP envía el mensaje endtx.

5.9 POLÍTICAS CAO EN LOS HUÉSPEDES VIRTUALES

Las políticas CAO se implementan localmente en los huéspedes virtuales mediante TOMOYO Linux. Las políticas CAO son administradas mediante los siguientes comandos:

a) sudo cat /tmp/file.txt >> /etc/tomoyo/domain_policy.conf b) sudo tomoyo-loadpolicy af c) sudo tomoyo-savepolicy

5.9.1 a) COMANDO sudo cat /tmp/file.txt >> /etc/tomoyo/domain_policy.conf

Mediante el comando anterior se adicionan nuevas políticas a los archivos de configuración de TOMOYO. Observar que el modificar los archivos de configuración no tiene efecto hasta que se apliquen las políticas CAO al kernel mediante el comando tomoyo-loadpolicy.

5.9.2 b) COMANDO sudo tomoyo-Ioadpolicy af

El comando tomoyo-loadpolicy carga las políticas que se encuentran en disco al kernel por medio de dos archivos de configuración:

b. l) exception _policy.conf b.2) domain_policy.conf

La opción f significa que se borrará la política actualmente en el kernel antes de cargar la política en disco. Si la opción f no es utilizada entonces la política existente a nivel archivo de configuración sera adicionada al kernel.

83

5.9.3 e) COMANDO sudo tomoyo-savepolicy

Con este comando se almacenan las políticas que se encuentran en ejecución en el kernel a disco. Se crean dos archivos:

c. l) /etc/tomoyo/ exception _policy .conf

c.2) /etc/tomoyo/domain_policy.conf

84

6. PRUEBAS

Se probó la implementación de PSCMV empleando un nodo maestro y dos huéspedes virtuales.

6.1 CARACTERÍSTICAS DE LOS NODOS UTILIZADOS DURANTE LA PRUEBA

6.1.1 NODO MAESTRO

El nodo maestro tiene las siguientes características: • Linux tomo03 2.6.32-24-ccs #41 SMP Fri Aug 20 09:35:01 JST 2010 i686 GNU/Linux • Ubuntu 10.04.1 LTS \n \1 • 512 MB RAM • 8 GB de espacio en disco • 1 procesador asignado • Network adapter VMNET 1 • MySQL Server version: 5.1.41-3ubuntul2.6 (Ubuntu) • Librerías adicionales instaladas: libmysqlclient-dev, libgcryptl 1-dev, mailutils y sharutils.

6.1.2 HUÉSPEDES VIRTUALES

Cada uno de los huéspedes virtuales tienen las siguientes características: • Linux tomoOX 2.6.32-24-ccs #41 SMP Fri Aug 20 09:35:01 JST 2010 i686 GNU/Linux • Ubuntu 10.04.1 LTS \n \1 • 512 MB RAM, 8 GB de espacio en disco • 1 procesador asignado • Network Adapter VMNETl • Librerías adicionales instaladas: libmysqlclient-dev, libgcryptl l-dev, mailutils y sharutils. • Servidor Apache/2 .2 .14 (Ubuntu)

85

6.1.3 NODO FISICO (PLATAFORMA DE VIRTUALIZACIÓN)

• Linux a8 2.6.27-17-server #1 SMP Fri Mar 12 02:48:52 UTC 201 O x86 64 GNU/Linux

• Ubuntu 8.10 \n \I • 4GBRAM

• 450 GB de espacio en disco

• l CPU X 4 Cores

• Intel(R) Xeon (R) CPU X3220 @ 2.40 GHZ

• Dell Power Edge R200

• VMWare Server 2.0.0 Build 122589 (Plataforma de virtualización)

6.2 PREPARACION DE LOS NODOS

6.2.1 NODO MAESTRO

En el nodo maestro se deben generar tanto la llave privada como la llave pública en formato PEM para poder trasmitir las políticas CAO al servicio SOP. En el código 32 se muestra el procedimiento de generación de las llaves en el nodo maestro.

Código 32. Generación de lla'\'es PEM en el nodo 111aestro # Generación de llave privada PEM a partir de llave privada RSA # openssl rsa -in -/.ssh/id_rsa -out mgkey.pem

# Generación de ta llave pública PEM a partir de ta llave # privada RSA # openssl rsa -pubout -in -/.ssh/id_rsa > mgarcia.pem

# Mostrar contenido de ta llave pública PEM # cat mgarcia.pem -----BEGIN PUBLIC KEY----MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEA18Z0aITLD/buqFX99PeH vcZ7z+0JuqHWeiiAL/EqKY0xplSW9lN0uHlNH4trpxS8MAhP9Ge0I2AD3FlRED7a T09wC7tieMXIDKYBf/nJKQsR6CldxpkDiX1U7JPkzs97VwCOa8zKBlzAYRdUVctl lW/526P6MnRSobij+X4ndRTE2SWVIotpvphXKkVr0HA9nhaAKwb8wGhk3uvqLNpE Tk6wnptSPE/cMusfUsyqUdBk9sVzka91yjTxqOpcr0yl3lGJTPuoWlFxYGEhkxT+ iPn40sXt6vyiYFqZfovZxQlj600SMQjJVwEloebsZPqJzt8/07YI8aHj8WWUNtdZ qwIBiw== -----END PUBLIC KEY-----

6.2.2 HUESPEDES VIRTUALES

En todos los huéspedes virtuales se debe copiar la llave pública del nodo maestro en fonnato PEM, dicha llave será utilizada por los huéspedes virtuales para la validación del nodo maestro.

86

6.3 INICIO DE LOS SERVICIOS

6.3.1 INICIO DEL SERVICIO SOP

En el código 33 se muestra el comando para iniciar el servicio SOP así como la salida del servicio. Mediante la opción -s se indica que se ejecutará el servicio en modo SOP (server) y la opción -p es utilizada para indicar el puerto TCP/IP en el cual el socket estará escuchando peticiones.

Cód!&o 33. Inicio del servicio SO _ _ _ ~---- _ ___ _ _ ___ _ _ install@tomo81:-/vmci$ ./vmciCao -s -p 8888

Protocolo inicializado pemPath: -/vmci pemPrivKeyPath: -/vmci pemPubKeyPath: -/vmci pemPrivKeyName: mgkey.pem pemPubKeyName: mgarcia.pem - Creando el socket en el huésped virtual (SOP) - Ligar socket a cualquier cliente - Información local del socket ...

* Local port: 8888 - Esperando al servicio STP ... Proceso 11196 padre escuchando

6.3.2 INICIO DEL SERVICIO STP

En el código 34 se muestra el comando para iniciar el servicio STP así como la salida del servicio. Mediante la opción -c se indica que se ejecutará el servicio en modo STP (cliente) y la opción -p es utilizada para indicar el puerto TCP /IP en el cual el socket del servicio SOP está escuchando peticiones.

87

,Cócligo 34_.Jnicio<!~l-~~ryicio STP !install@tomo83:-/vmci$ ./vmciCao -e -p 8988

I P l · · · l' d · rotoco o 1n1c1a iza o pemPath: -/vmci pemPrivKeyPath: -/vmci

·pemPubKeyPath: -/vmci pemPrivKeyName: mgkey.pem. pemPubKeyName: mgarcia.pem sopHostName: tomo01 pemPath: -/vmci pemPrivKeyName: mgkey.pem pemPrivKeyPath: -/vmci pemPubKeyName: mgarcia.pem

pemPubKeyPath: -/vmci Parámetros leidos de la B.O. - Creando un socket en el huésped virtual administrativo (STP) - Conectando el socket al huésped virtual (SOP) - Enviando al puerto: 8888

6.4 INTERCAMBIO DE DA TOS ENTRE LOS SERVICIOS

6.4.1 SERVICIO STP

En el código 35 se muestra el intercambio de mensajes del servicio STP con el servicio SOP.

Cód_igo 35. Intercambio de mensajes, ~~ry_i_cj<> _5_'J'P. Partt! 1 Valor de protocolinitPos -------------> 6

! [SOCKET-sendTo] Bytes sent: 7 ' [CLIENT] Bytes sent: sendcao Esperando respuesta del servicio SOP(server) [SOCKET-receiveFrom] Bytes recibidos: 21 RecBuf: acksendcao-1161550272 Challenge: -1161559272 buffChallenge: openssl dgst -sha256 -sign -/vmci/mgkey.pem -out

l/tmp/challenge.sha256 /tmp/challenge.txt

1buffChallenge: uuencode /tmp/challenge.sha256 /dev/stdout > /tmp/challenge.uu'

[SOP] Bytes recibidos: acksendcao

Valor de protocolinitPos -------------> 8 [SOCKET-sendTo) Bytes sent: 392

88

_Código 36.Jntf:!c:ambio c.ie _111_ensajes, serviciº_~'f P. PaJ:tf: 2 [CLIENT] Bytes sent: datainitbegin 644 /dev/stdout

MKT)UV+[G&8,0W/)RZ5=W@?D1L*#QF]90U89WSS "T@l!WV,QD2IV/>0$"6(5 MVGB'MT@:ND446N)Vl+T.R?#*>)WOR"14 SR%P:"%@MH-R(ME)":QP)\3:>H' MV2LNQA3, [NS'WU&GM<QP#R?U=NX\$WPJ/YJ)F>B@B "E(5A.6[5YK4WBIR]9 MNEV-B]R.-NDV)/%)KK85*6:EW.0"070>23HD+0G+-SB=I@U?:(EJA6U T$C% MT?E>AMP4CQKB'<YVLN&<>5]05$V7 9APL[< 9=*%$@$5-'3KW+=.WM2*Z!\F ?[$BGD\F!,%9UNA])HR[Z$847\-@)?+#DL20]QDLU.@''

end Valor de protocolinitPos -------------> 9

[INFO DE LA B.O.] 1 0 <kernel> /etc/init.d/rc /etc/init.d/apache2 [SOCKET-sendTo] Bytes sent: 43

[STP] Bytes enviados: <kernel> /etc/init.d/rc /etc/init.d/apache2 [SOCKET-receiveFrom] Bytes recibidos: 64

,SHA2 enviado: Bf0a2711Beabc34ee13101a08fbaaea443650fdd3d58a307e587bf464493402a SHA2 recibido: 8f0a27118eabc34ee13191a08fbaaea443650fdd3d58a307e587bf464493402a SHA2 paso la prueba ...

[SOP] Bytes recibidos: 8f0a27118eabc34ee1310la08fbaaea443650fdd3d58a307e587bf464493402a

[INFO DE LA B.O.] 1 1 use_profile 3 . [SOCKET-sendTo] Bytes sent: 13

[STP] Bytes enviados: use profile 3 [SOCKET-receiveFrom] Bytes recibidos: 64 SHA2 enviado:

.2de72f8608c38041590ba138aeale533a195bcbe039cc797d7a2335dllf4e447 SHA2 recibido: 2de72f8608c38041590ba138aeale533a195bcbe039cc797d7a2335dllf4e447 SHA2 paso la prueba ...

[SOP] Bytes recibidos: 2de72f8608c38041590bal38aeale533a195bcbe039cc797d7a2335dllf4e447

[INFO DE LA B.O.] 1 2 allow execute /usr/bin/env [SOCKET-sendTo] Bytes sent: 26 -

[STP] Bytes enviados: allow_execute /usr/bin/env [SOCKET-receivefrom] Bytes recibidos: 64 SHA2 enviado: 2563f5b69b62083a2cfac0afla5cefbb73304fe074e83f63296c7cdc31076b74 SHA2 recibido: 2563f5b69b62083a2cfac0afla5cefbb73304fe074e83f63296c7cdc31076b74 SHA2 paso la prueba ...

[SOP] Bytes recibidos: 2563f5b69b62083a2cfac0afla5cefbb73304fe074e83f63296c7cdc31076b74

[INFO DE LA B.O.] 1 3 allow_execute /usr/bin/expr [SOCKET-sendTo] Bytes sent: 27

[STP] Bytes enviados: allow_execute /usr/bin/expr [SOCKET-receiveFrom] Bytes recibidos: 64 SHA2 enviado: 79edb7c3cef22ba53e3dcb600d3a7c9c8953c3b4bc0b09c69dll970bcf972165 SHA2 recibido: 79edb7c3cef22ba53e3dcb600d3a7c9c8953c3b4bc0b09c69dll970bcf972165

·SHA2 paso la prueba ...

89

Código 37. Intercambio de mensajes, servicio STP. Parte 3 [SOPJ Bytes recibidos:

79edb7c3cef22ba53e3dcb600d3a7c9c8953c3b4bc0b09c69d11970bcf972165 [INFO DE LA B.D.] 1 4 allow execute /usr/bin/tput

[SOCKET-sendTo] Bytes sent: 27 -[STPJ Bytes enviados: allow_execute /usr/bin/tput

[SOCKET-receiveFrom] Bytes recibidos: 64 SHA2 enviado:

'b66c87ce831eb62a31dee4880492a68a4a0dfd514965cabe3e15254104c07902 ·sHA2 recibido: b66c87ce831eb62a31dee4880492a68a4a0dfd514965cabe3e15254104c07902 SHA2 paso la prueba ...

[SOP] Bytes recibidos: b66c87ce831eb62a31dee4880492a68a4a0dfd514965cabe3e15254104c07902

[INFO DE LA B.D.] 1 5 allow read /bin/dash · [SOCKET-sendTo] Bytes sent: 20 -

[STPJ Bytes enviados: allow_read /bin/dash [SOCKET-receiveFrom] Bytes recibidos: 64

.SHA2 enviado: itb37d907f8895f0c8d863b80ca0763e4a7756db3aa1872f63523431e428bbld4 ·SHA2 recibido: fb37d907f8895f0c8d863b80ca0763e4a7756db3aa1872f63523431e428bbld4 SHA2 paso la prueba ...

· [SOP] Bytes recibidos: 'tb37d907f8895f0c8d863b80ca0763e4a7756db3aa1872f63523431e428bbld4

[INFO DE LA B.D.J 1 6 allow read /etc/apache2/envvars [SOCKET-sendTo] Bytes sent: 31 -

[STP] Bytes enviados: allow read /etc/apache2/envvars [SOCKET-receiveFrom] Bytes recibidos: 64 SHA2 enviado: 2b910f6f5ccc02bc7cb5abcc5766f85fd29329aa2c5b4f2dadc3Beb13bb88e3d SHA2 recibido: 2b910f6f5ccc02bc7cb5abcc5766f85fd29329aa2c5b4f2dadc38eb13bb88e3d ... SHA2 paso la prueba ...

[SOP] Bytes recibidos: 2b910f6f5ccc02bc7cb5abcc5766f85fd29329aa2c5b4f2dadc38eb13bb88e3d

. [INFO DE LA B.D.] 1 7 allow_read /etc/default/apache2 : [SOCKET-sendTo] Bytes sent: 31

[STPJ Bytes enviados: allow_read /etc/default/apache2 : [SOCKET-receiveFrom] Bytes recibidos: 64 !SHA2 enviado: 5691fce33910feeefd0a5505c6bbd3366aebc2b4570fd37bb35754eb44904644 SHA2 recibido: 5691fce33910feeefd0a5505c6bbd3366aebc2b4570fd37bb35754eb44904644 SHA2 paso la prueba ...

[SOPJ Bytes recibidos: 5691fce33910feeefd0a5505c6bbd3366aebc2b4570fd37bb35754eb44904644

[INFO DE LA B.D.] 1 8 allow read /etc/default/rcS • [SOCKET-sendTo] Bytes sent: 27 -

[STP] Bytes enviados: allow_read /etc/default/rcS

90

Código 38. Intercambio de mensajes, servicio STP. Parte 4 [SOCKET-receiveFrom] Bytes recibidos: 64 SHA2 enviado: 6fd0e47d248c796a2f0cal54eab2528afl32bcff4f6f3447c32e14bec6a857eb SHA2 recibido: 6fd0e47d248c796a2f0ca154eab2528af132bcff4f6f3447c32e14bec6a857eb SHA2 paso la prueba ...

[SOP] Bytes recibidos: 6fd0e47d248c796a2f0ca154eab2528af132bcff4f6f3447c32e14bec6a857eb

[INFO DE LA B.O.] 1 9 allow_read /etc/init.d/apache2 [SOCKET-sendTo] Bytes sent: 30

[STP] Bytes enviados: allow_read /etc/init.d/apache2 [SOCKET-receiveFrom] Bytes recibidos: 64 SHA2 enviado: 5848d7d7dc71flf216d36bf10clecc26b8c59ba9446e3e3a17c6e24d53404426 SHA2 recibido: 5848d7d7dc71flf216d36bf10clecc26b8c59ba9446e3e3a17c6e24d53404426 SHA2 paso la prueba ...

[SOP] Bytes recibidos: 5848d7d7dc71flf216d36bfl0clecc26b8c59ba9446e3e3a17c6e24d53404426

[INFO DE LA B.O.] 1 10 allow_read /etc/lsb-base-logging.sh [SOCKET-sendTo] Bytes sent: 35

[STP] Bytes enviados: allow_read /etc/lsb-base-logging.sh [SOCKET-receiveFrom] Bytes recibidos: 64 SHA2 enviado: 5c1994bf35ac2354cda42642dd4211c7d4459d61d83939bac7064cbf21c0cf32 SHA2 recibido: 5c1994bf35ac2354cda42642dd4211c7d4459d61d83939bac7064cbf21c0cf32 SHA2 paso la prueba ...

[SOP] Bytes recibidos: 5c1994bf35ac2354cda42642dd4211c7d4459d61d83939bac7064cbf21c0cf32

[INFO DE LA B.O.] 1 11 allow_read /lib/lsb/init-functions [SOCKET-sendTo] Bytes sent: 34

[STP] Bytes enviados: allow read /lib/lsb/init-functions [SOCKET-receiveFrom] Bytes recibidos: 64 SHA2 enviado: 144085d0dle66c7c659fc186f0292b77eclb93780fc4099328e17bb41d24b427 SHA2 recibido: 144085d0dle66c7c659fc186f0292b77eclb93780fc4099328e17bb41d24b427 SHA2 paso la prueba ...

[SOP] Bytes recibidos: 144085d0dle66c7c659fc186f0292b77eclb93780fc409932Be17bb4ld24b427

[INFO DE LA B.O.] 1 12 allow_truncate /dev/null [SOCKET-sendTo] Bytes sent: 24

[STP] Bytes enviados: allow_truncate /dev/null [SOCKET-receiveFrom] Bytes recibidos: 64 SHA2 enviado: 78eb3796d47bfa8ale13d7c9ea9c28c35efe7c307724748901ef5c38949d5e2d SHA2 recibido: 78eb3796d47bfa8ale13d7c9ea9c28c35efe7c307724748901ef5c38949d5e2d SHA2 paso la prueba ...

91

.Código 39. Intercambio de mensajes, servicio STP. Parte5 · [SOP] Bytes recibidos: 78eb3796d47bfa8ale13d7c9ea9c28c35efe7c307724748901ef5c38949d5e2d

[INFO DE LA B.O.] 1 13 allow write /dev/null i [SOCKET-sendTo] Bytes sent: 21 -

[STP] Bytes enviados: allow write /dev/null [SOCKET-receiveFrom] Bytes recibidos: 64 SHA2 enviado: 0c7b32cc2c03cf9a4da9d07570c6f982b7227d4192de648b9a600487de96cdal SHA2 recibido: 0c7b32cc2c03cf9a4da9d07570c6f982b7227d4192de648b9a600487de96cdal SHA2 paso la prueba ...

[SOP] Bytes recibidos: 0c7b32cc2c03cf9a4da9d07570c6f982b7227d4192de648b9a600487de96cdal Valor de protocolinitPos-------------> 10 Valor de protocolinitPos -------------> 10 [SOCKET-sendTo] Bytes sent: 7

[CLIENT] Bytes sent: dataend Esperando respuesta del servicio SOP(server) [SOCKET-receiveFrom] Bytes recibidos: 5 Actualizando la tabla server policies ...

[SOP] Bytes recibidos: endtx

6.4.2 SERVICIO SOP

En el código 40 se muestra el intercambio de mensajes del servicio STP con el servicio SOP.

Código 40. Intercambio de mensajes, servicio SOP. Parte 1 Proceso 1642 con padre 1641 escuchando [SOCKET-receiveFrom] Bytes recibidos: 7 ===> protocolinitPos 0 [CLIENT] Bytes rec: sendcao

· ===> Va lid: true Challenge to send: acksendcao-1161550272:21 [SOCKET-sendTo] Bytes sent: 21 Bytes tx to client: 21 [SERVER] Bytes sent: acksendcao

, [SOCKET-receiveFrom] Bytes recibidos: 392 Signed digest: begin 644 /dev/stdout MKT)UV+[G&8,0W/)RZ5=W@?Dll*#QF)90U80WSS_"T@l!WV,QD2IV/>0$"6(5 MVGB'MT@:ND446N)Vl+T.R?#*>)WOR"14 SR%P:"%@MH-R(ME)":QP)\3:>H' MV2LNQÁ3,[NS'WU&GM<QP#R7U=NX\$WPJ/YJ)F>B@8_"E(5A.6[5YK4W8IR]9 MNEV-B]R.-NDV)/%)KK85*6:EW.0"070>23HD+0G+-5B=I@U?:(EJA6U T$C% MT?E>AMP4CQKB'<YVLN&<>5]05$V7 9APL[< 9=*%$@$5-'3KW+=.WM2*Z!\F ?[$BGD\F!,%9UNA])HR[Z$847\-@)?+#DL20]QDLU.@''

end Verified OK

92

Código 41. Int~i::cambie> de_ mensajes1 servicio ~O P. Parte2 ===> protocolinitPos 2 [CLIENT] Bytes rec: datainit ===> Valid: true [SOCKET-receiveFrom] Bytes recibidos: 43 ===> protocolinitPos 4 [CLIENT] Bytes rec: <kernel> /etc/init.d/rc /etc/init.d/apache2 ===> Valid: false [SOCKET-sendTo] Bytes sent: 64 Bytes tx to client:8f0a27118eabc34eel310la08fbaaea443650fdd3d58a307e587bf464493402a - 64 [SOCKET-receiveFrom] Bytes recibidos: 13 ===> protocolinitPos 4

¡ [CLIENTJ Bytes rec: use_profile 3 ,===> Valid: false 1 [SOCKET-sendTo] Bytes sent: 64 1 Bytes tx to client:2de72f8608c38041590bal3Baeale533a195bcbe039cc797d7a2335dllf4e447 - 64

. [SOCKET-receiveFrom] Bytes recibidos: 26 i===> protocolinitPos 4 i [CLIENT] Bytes rec: allow execute /usr/bin/env ===> Valid: false -

i[SOCKET-sendTo] Bytes sent: 64 ¡By~es tx to cl1ent:2563f5b69b62083a2cfac0afla5cefbb73304fe074e83f63296c7cdc31076b74 - 64

• [SOCKET-receiveFrom] Bytes recibidos: 27 :===> protocolinitPos 4 i [CLIENT] Bytes rec: allow_execute /usr/bin/expr ===> Valid: false [SOCKET-sendTo] Bytes sent: 64 Bytes tx to client:79edb7c3cef22ba53e3dcb600d3a7c9c8953c3b4bc0b09c69dl1970bcf972165 - 64 [SOCKET-receiveFrom] Bytes recibidos: 27 ===> protocolinitPos 4 [CLIENT] Bytes rec: allow_execute /usr/bin/tput ===> Valid: false [SOCKET-sendTo] Bytes sent: 64

\Bytes tx to · :client:b66c87ce831eb62a31dee4880492a68a4a0dfd514965cabe3e15254104c07902 - 64 i [SOCKET-receiveFrom] Bytes recibidos: 20 ! ===> protocolinitPos 4 [CLIENT] Bytes rec: allow_read /bin/dash ===> Valid: false [SOCKET-sendTo] Bytes sent: 64 Bytes tx to

'client:fb37d907f8895f0c8d863b80ca0763e4a7756db3aa1872f63523431e42Bbbld4 - 64 [SOCKET-receiveFrom] Bytes recibidos: 31 ===> protocolinitPos 4 [CLIENT] Bytes rec: allow_read /etc/apache2/envvars ===> Valid: false [SOCKET-séndTo] Bytes sent: 64 Bytes tx to client:2b910f6f5ccc02bc7cb5abcc5766f85fd29329aa2c5b4f2dadc3Beb13bb88e3d - 64 [SOCKET-receiveFrom] Bytes recibidos: 31

93

,CQcijgº42.J-1!!_€?!~ªQ!bio_cl~_g1e_nsaje_s, servicio SQP. Parte 3 i===> protocolinitPos 4 [CLIENTJ Bytes rec: allow_read /etc/default/apache2 ===> Valid: false [SOCKET-sendToJ Bytes sent: 64 Bytes tx to client:5691fce33910feeefd0a5505c6bbd3366aebc2b4570fd37bb35754eb44904644 - 64 [SOCKET-receiveFrom] Bytes recibidos: 27 ===> protocolinitPos 4 [CLIENTJ Bytes rec: allow_read /etc/default/rcS ===> Valid: false [SOCKET-sendTo] Bytes sent: 64 Bytes tx to client:6fd0e47d248c796a2f0ca154eab2528af132bcff4f6f3447c32e14bec6a857eb - 64

. [SOCKET-receiveFrom] Bytes recibidos: 30 ===> protocolinitPos 4

· [CLIENT] Bytes rec: allow read /etc/init.d/apache2 ===> Valid: false -[SOCKET-sendTo] Bytes sent: 64 Bytes tx to client:5848d7d7dc71flf216d36bf10clecc26b8c59ba9446e3e3a17c6e24d53494426 - 64

· [SOCKET-receiveFrom] Bytes recibidos: 35 ===> protocolinitPos 4 [CLIENT] Bytes rec: allow read /etc/lsb-base-logging.sh ===> Valid: false -[SOCKET-sendTo] Bytes sent: 64 Bytes tx to client:Sc1994bf35ac2354cda42642dd4211c7d4459d61d83939bac7964cbf21c9cf32 - 64

: [SOCKET-receiveFrom] Bytes recibidos: 34 ===> protocolinitPos 4 [CLIENT] Bytes rec: allow_read /lib/lsb/init-functions ===> Valid: false [SOCKET-sendTo] Bytes sent: 64 Bytes tx to client:144085d0dle66c7c659fc186f0292b77eclb93780fc4099328e17bb41d24b427 - 64

· [SOCKET-receiveFrom] Bytes recibidos: 24 ===> protocolinitPos 4 [CLIENT] Bytes rec: allow_truncate /dev/null ===> Valid: false

. [SOCKET-sendTo] Bytes sent: 64 Bytes tx to client:78eb3796d47bfa8ale13d7c9ea9c28c35efe7c307724748901ef5c38949d5e2d - 64 [SOCKET-receiveFrom] Bytes recibidos: 21 ===> protocolinitPos 4 [CLIENT] Bytes rec: allow_write /dev/null ===> Valid: false [SOCKET-sendTo] Bytes sent: 64

.Bytes tx to •client:0c7b32cc2c93cf9a4da9d07579c6f982b7227d4192de648b9a600487de96cdal - 64 '[SOCKET-receiveFrom] Bytes recibidos: 7 ·===> protocolinitPos 4 [CLIENTJ Bytes rec: dataend ===> Valid: true

94

6.5 APLICACION DE POLITICAS CAO

6.5.l SERVICIO SOP

En el código 43 se observa el procedimiento de aplicación de políticas CAO por parte del servicio SOP.

Código 43. A¡,licación de ¡,olíticas CAO por el servicio SOP r------- . -- - ----·---- - --------- -·------ --------------- ------- ------ --------------- -------

[SQ(KET-SendTO] Bytes sent: 5 Bytes tx to client: 5 [SERVER] Bytes sent: endtx <kernel> /etc/init.d/rc /etc/init.d/apache2 use_profile 3 allow execute /usr/bin/env

1

allow-execute /usr/bin/expr allow-execute /usr/bin/tput allow-read /bin/dash

,allow=read /etc/apache2/envvars 'allow_read /etc/default/apache2 allow read /etc/default/rcS allow-read /etc/init.d/apache2 allow=read /etc/lsb-base-logging.sh allow_read /lib/lsb/init-functions

,allow truncate /dev/null allow=write /dev/null

'Reset ! 1

. !

95

7. CONCLUSIONES

En este trabajo de tesis se diseñó e implemento la arquitectura PSCMV, de tal forma que la administración de políticas CAO sea más sencilla y flexible. Mediante esta arquitectura, las políticas CAO de los huéspedes virtuales se administran de manera centralizada desde una máquina virtual llamada nodo maestro.

La arquitectura PSCMV se implementó utilizando la plataforma de virtualización VMWare Server 2.0.0 y se empleó el esquema CAO de TOMOYO. El esquema TOMOYO fue seleccionado dado que a partir del 2009 se incluyó en el kernel de Linux en la versión 2.6.30 (Junio 2009) [49].

Los servicios STP y SOP fueron codificados mediante VMCI Sockets (VMWare communication Sockets). La implementación de la arquitectura puede ser fácilmente convertida a sockets tradicionales con muy pocos cambios en el código fuente, y al estar utilizando sockets tradicionales la implementación podría ser utilizada en servidores físicos así como en otras platafom1as de virtualización.

La implementación actual de la arquitectura incluye los siguientes rubros: almacenamiento de políticas CAO en el repositorio CAO, transmisión de políticas CAO hacia los huéspedes virtuales y la aplicación de las políticas CAO en los huéspedes virtuales.

La implementación de la arquitectura PSCMV resultó ser de mucha utilidad para la administración de políticas CAO desde una máquina centralizada. De acuerdo a las pruebas realizadas tanto en el nodo maestro como en los huéspedes virtuales se observó que PSCMV no tiene impacto alguno en el desempeño de los equipos virtuales (no representa una sobrecarga importante en los nodos).

La arquitectura PSCMV al momento solamente soporta la administración de políticas CAO en huéspedes virtuales basados en Linux. Se planea en el futuro soportar máquinas virtuales con otros sistemas operativos, tal como Windows y MacOS; asimismo, en el futuro se planea soportar otros esquemas CAO, tal como AppArmor, LIDS y TRUSTEES.

96

8. REFERENCIAS [1] Dragovic, B., K. Fraser, S. Hand, T. Harris, A. Ho, I. Pratt, A. Warfield, P. Barham, R. Neuge-bauer, "Xen and the art of virtualization," Proceedings of the ACM Symposium on Operating Systems Principles, 2003.

[2] Pratt, I., K. Fraser, S. Hand, C. Limpach, A. Warfield, D. Magenheimer, J. Nakajima, A. Mallick, "Xen 3.0 and the art of virtualization," Proceedings of the 2005 Ottawa Linux Symposium, Ottawa, Canada, 2005.

[3] Xen project, Xen virtual machi ne monitor, 2006, http://www.cl.cam.ac. uk/Research/SRG/netos/xen/.

[4] Xen Project, Xen Interface Manual, Retrieved on September 2009 from http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/interface/interface.html.

[5] Kroah-Hartman, Greg, Driving Me Nuts - Things You Never Should Do in the Kernel, Retrieved on September 2009 from http://www.linuxjoumal.com/article/8110.

[6] DOD 5200.28-STD: Department of defense trusted computer system evaluation criteria, 1985.

[7] Smalley, S., C. Vanee, W. Salamon, Implementing SELinux as a Linux Security Modulep Nai labs report, NAI Labs, 2005.

[8] LIDS team, Linux Intrusion Detection System, Retrieved on September 2009 from http://www.lids.org.

[9] Ruder, Andrew, Trustees ACL, Retrieved on September 2009 from http://trustees.aeruder.net/.

[ 1 O] AppArmor team, AppArmor project, Retrieved on September 2009 from http://en.opensuse.org/ Apparmor.

[11] Cowan, C., S. Beattie, G. Kroah-Hartman, C. Pu,P. Wagle, V. Gligor, "SubDomain: Parsimonious server security," 14th USENIX Systems Administration Conference (LISA 2000), New Orleans, LA, 2000.

97

[12] Clark, B., T. Deshane, E. Dow, S. Evanchik, M. Finlayson, J. Heme, J. N. Matthews, "Xen and the art ofrepeated research," Proceedings of the Usenix annual technical conference, Freenix track,pp. 135-144,2004.

[13] T. Jaeger, R. Sailer, and X. Zhang. Analyzing Integrity Protection in the SELinux Example Policy. In 12th USENIX Security Sumposyum, UNSENIX 2003.

[14] P. A. Karger and R. R. Schell. Thirty Years Later: Lessons from the Multics Security Evaluation. In Annual Computer Security Applications Conference (ACSAC), December 2004.

[15] R. Meushaw amd D. Simard. NetTop - Commercial Technology in High Assurance Applications. Tech Trend Notes. Fall 2000.

[16] National Security Agency. Security-Enhanced Linux (SELinux). Retrieved on September 2009 from http://www.nsa.gov/selinux.

[17] Kroeker, K.L. 2009. "The Evolution of Virtualization," Association for Computing Machinery. Communications of the ACM (52:3), p 18.

[ 18] Waters, John K (2007) ABC: An Introduction to Virtualization-CIO, Retrieved on March 2010 From: http://www.cio.com

[19] Purush, R., Bhagvat, S., Weldon, R., Douglas, B., & Schmidt, D. (2008) Getting Started with Microsoft Windows Server 2008 Hyper-V on Dell Servers. Retrieved 16 April 2009 from http://viewer.bitpipe.com/viewer/viewDocwnent.do?accessld=9381622

[20] RSBAC Team, RSBAC: Extending Linux Security Beyond the Limits, 2006, Retrieved on April 2010 From http://www.rsbac.org/.

[21] Spengler, Brad, Grsecurity, 2006, Retrieved on April 2010 From http://www.grsecurity.net/.

[22] Susanta Nanda, Tzu-cker Chiueh. "A Survey on Virtualization Technologies", Department of Computer Science. SUNY at Stony Brook, NY, 2005.

[23] J. P. Walters, V. Chaudhary, M. Cha, S. Guercio Jr, and S. Gallo. A Comparison of Virtualization Technologies for HPC. In Proceedings of the 22nd Intemational Conference on Advanced Information Networking and Applications, pages 861-

868. IEEE Computer Society, 2008.

[24] VMware, Inc. 3401 Hillview Ave Palo Alto. "VMware Server 2 - A Risk-Free Way to Get Started with Virtualization" www.vmware.com.

[25] K. Kolyshkin, "Virtualization in Linux." http://download.openvz.org/doc/openvz-intro.pdf.

[26] H. Potzl, "Linux-VServer." http://en.wikipedia.org/wiki/Linux-VServer.

98

[27] Irfan Habib, Virtualization with KVM, Linux Joumal, v.2008 n.166, p.8, February 2008.

[28] Deqing Zou, Lei Shi, Hai Jin, "DVM-MAC: A Mandatory Access Control System in Distributed Virtual Computing Environment," Parallel and Distributed Systems, International Conference on, pp. 556-563, 2009 l 5th Intemational Conference on Parallel and Distributed Systems, 2009.

[29] N.A. Quynh, R. Ando, and Y. Takefuji. Centralized security policy support for virtual machi ne. In LISA '06: Proceedings of the 20th conference on Large Installation System Administration, pages 79-87, Berkeley, CA, USA, 2006. USENIX Association.

[30] P. Loscocco and S. Smalley, "Integrating Flexible Support for Security Policies into the Linux Operating System," in Proc. Free and Open Source Software (FREENIX) Track: 2001 USENIX Annual Technical Conference (FREENIX '01), June 2001.

[31] C. Schaufler, "The Simplified Mandatory Access Control Kernel," March 2008, the document is a whitepaper under development. [Online]. Available: http://www.schauflerca.com/data/SmackWhitePaper.pdf.

[32] Novell. (2007, October) Novell AppArmor (2.1) Quick Start. Novell. [Online]. Available: http://www.novell.com/documentation/apparmor/.

[33] --. (2007, September) Novell AppArmor Administrator Guide 2.1.Novell. [Online]. A vailable: http://www.novell.com/documentation/apparmor/.

[34] M. Jawurek. (2005) RSBAC - a framework for enhanced Linux system security. Proc. conference seminar laboratory of Dependable Distributed Systems at RWTH Aachen University. RWTH-Aachen University, Aachen, Germany. [Online]. Available: http://www.rsbac.org/doc/media/rsbac-marek2006. pdf.

[35] A. Ott and S. Fischer-Hbner. Toe Rule Set Based Access Control (RSBAC) Framework for Linux. ISBN 91-89422-63-5. Karlstad University Studies. [Online]. Available: http://www.rsbac.org/doc/media/rsbac-framework. pdf.

[36] A. Ott. (2001, November) The Rule Set Based Access Control (RSBAC) Linux Kernel Security Extension. 8th Intemational Linux Kongress. Enschede. [Online]. Available: http://www.rsbac.org/doc/media/linux-kongress.pdf.

[37] --. (2002, October) The Role Compatibility Security Model. Nordsec 2002, 7th Nordic Workshop on Secure IT Systems. Karlstad, Sweden. [Online]. Available: http://www.rsbac.org/doc/media/rc-nordsec2002.pdf.

99

[38] R. Watson, B. Feldman, A. Migus, and C. Vanee, "Design and Im plementation of the TrustedBSD MAC Framework," in Proc. Defense Advanced Research Projects Agency (DARPA) lnformation Survivability Conference and Exposition, April 2003, pp. 38-49.

[39] HP-UX l li Security Containment Administrator's Guide, HP-UX l li v2 ed., E0606, Hewlett-Packard, March 2007, Version B.11.23.02, Part Number 5991-8678. [Online]. Available: http://docs.hp.com/en/5991-8678/5991-8678.pdf.

[40] S. Smalley, C. Vanee, and W. Salomon, "lmplementing SELinux as a. linux security module", Technical Report 01-403, NAI Labs, 2001.

[41] . R. Watson, W. Morrison, C. Vanee, and B. Feldman, "The TrustedBSD MAC framework: Extensible kernel access control for FreeBSD 5.0", Proceedings of the USENIX Annual Technical Conference, June 2003, pp.285-296.

[42] . P. Loscocco and S. Srnalley, "Integrating flexible support for security policies into the Linux operating system", Proceedings of the FREENIX track: 2001 USENIX annual technical conference, June 2001, pp.29-42.

[43] W.E. Boebert and R. Y. Kain, "A practica! altemative to hierarchical integrity policies", Proceedings of the National Computer Security Conference, 1985, pp.18-27.

[44] D. E. Bell and L. J. LaPadula "Secure computer systems: Mathematical foundations and model", Technical Report ESD-TR-75-306, Toe Mitre Corporation, Air Force Electronic Systems Division, Hanscom AFB, Badfor, MA, 1976.

[45] Harsha, K., Palavalli, B. M., Rao, S., and Ashwin, A. 2009. Lothlorien: mandatory access control using linux security modules. In Proceedings of the 3rd IEEE international Conference on internet Multimedia Services Architecture and Applications (Bangalore, India, December 09 -11, 2009). IEEE Press, Piscataway, NJ, 211-216.

[46] N. Li, B.N. Grosof, and J. Feigenbaum, "Delegation logic: A logic-based approach to distributed authorization", ACM Transactions on Information and System Security, February 2003, 6(1):128-171.

[47] N. Li and J.C. Mitchell, "Understanding SPKI/SDSI using first-order logic", Proceedings of the IEEE Computer Security Foundations Workshop, June 2003, pp.89-103.

[ 48] J McCune, S. Berger, R. Cacerres, T. Jaeger, and R. Sailer, "Shamon: A system for distributed mandatory access control", Proceedings of the 22st annual Computer security Conference, December 2006, pp.23-32.

[49] J. Corbet (2008, April) TOMOYO Linux and pathname-based security. LWN Net. [Online]. A vailable: http://lwn.net/ Articles/277833/.

100

Políticas de seguridad centralizadas para máquinas virtuales

Documents

Transcript of Políticas de seguridad centralizadas para máquinas virtuales