Políticas de seguridad centralizadas para máquinas virtuales

Texto completo

(1)INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE CAMPUS ESTADO DE MÉXICO. POLÍTICAS DE SEGURIDAD CENTRALIZADAS PARA MÁQUINAS VIRTUALES TESIS QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS DE LA COMPUTACION PRESENTA. MANUEL ANTONIO GARCÍA CHANG Asesor:. 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..

(2) 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.

(3) 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.

(4) 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.

(5) 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.

(6) 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.

(7) 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 1O. 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.

(8) 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.

(9) ABREVIATURAS Y SIMBOLOS -------------------·------------- -------,. i__. --- - ----. ------·---·--. ·--. - -. ----·-. ---·-·-·----------------------------------------. ----~~~!·-~~~---------1--------------- __________. -- - - - ------·-. Desci¿_pción_________________. --. .. ~. _ -1. lCAOV. · Control de Acceso Obligatorio. ¡. ¡. IControl de Acceso Obligatorio para Máquinas Virtuales. !. I MAC. : Mandato[)' Access Control. j. CAO. -- - --- --- ------------------ - - - - - - - - - - - - l - - - - - - - - - - - - - - - - - - - - - - - - - - --- ------------------------------------ - --------1. 1- ·----- - --- ··- ·--------------·-------t---·--------- -----·-·--·- ---····---- ·-------- ·- --------··· -----·------- - ·-----------------·----------------------~. ---~=:--=-~=-~~-::::~=-====-~--=--- -; ==---== i;:.;.:;;. ~---=-=--------------------=-~:~=~---=-~·-:---~-.--:~j,. ¡-MV- ------. ¡:;. ¡ PSCMV i -. --. i Máquina Vi~I- -. -_- -_-- _---. ! Políticas de Seguridad Centralizadas para Máquinas Virtuales ------------t= ---------------------------------------- - -- -----------. ISO. , Sistema Operativo. l. ________________l__ _ _ _ _ _ _ _ _ _ _ _ _. 1. ---------------------------------------------------------. 11.

(10) 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.

(11) 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.

(12) 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.

(13) 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.

(14) 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. ESTRATEGÍ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.

(15) 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.

(16) 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.

(17) 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. OpenVZ 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, OpenVZ es capaz de lograr un nivel de granularidad en el control de recursos que no pueden la virtualización completa ni la paravirtualización. OpenVZ 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 VMWare, 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.

(18) 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.,..,-<;:,. ~C~. 1,\\'\ DEEJr¿,0 ~~~.20. 'I1..sr.~,j ~~h~"i $¡ •. .()~""O. ~~Oo. o. ~{. ~ :"__~,1.~'Y. ...... ~.

(19) 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.

(20) • •. 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.

(21) 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.

(22) • • • • • • •. 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.

(23) 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.

(24) 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.

(25) 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.