El control de integridad obligatorio ( MIC ) es una característica de seguridad central de Windows Vista y versiones posteriores que agrega procesos de ejecución de control de acceso obligatorios en función de su nivel de integridad (IL). El IL representa el nivel de confiabilidad de un objeto. El objetivo de este mecanismo es restringir los permisos de acceso para contextos potencialmente menos confiables (procesos, archivos y otros objetos protegibles), en comparación con otros contextos que se ejecutan bajo la misma cuenta de usuario que son más confiables.
Implementación
El control de integridad obligatorio se define mediante un nuevo tipo de entrada de control de acceso (ACE) para representar el IL del objeto en su descriptor de seguridad . En Windows, las listas de control de acceso (ACL) se utilizan para otorgar derechos de acceso (leer, escribir y ejecutar permisos) y privilegios a usuarios o grupos. Un IL se asigna al token de acceso de un sujeto cuando se inicializa. Cuando el sujeto intenta acceder a un objeto (por ejemplo, un archivo), el Monitor de referencia de seguridad compara el nivel de integridad en el token de acceso del sujeto con el nivel de integridad en el descriptor de seguridad del objeto . Windows restringe los derechos de acceso permitidos dependiendo de si el IL del sujeto es mayor o menor que el del objeto, y dependiendo de los indicadores de la política de integridad en la nueva entrada de control de acceso (ACE). El subsistema de seguridad implementa el nivel de integridad como una etiqueta obligatoria para distinguirlo del acceso discrecional bajo el control del usuario que proporcionan las ACL.
Windows Vista define cuatro niveles de integridad: Bajo ( SID : S-1-16-4096), Medio ( SID: S-1-16-8192), Alto ( SID: S-1-16-12288) y Sistema ( SID : S-1-16-16384). [1] De forma predeterminada, los procesos iniciados por un usuario regular obtienen un IL medio y los procesos elevados tienen un IL alto . [2] Al introducir niveles de integridad, MIC permite aislar clases de aplicaciones, lo que permite escenarios como aplicaciones potencialmente vulnerables en un entorno de pruebas (como aplicaciones orientadas a Internet ). Los procesos con IL bajo se denominan procesos de baja integridad, que tienen menos acceso que los procesos con IL más altos donde la aplicación del control de acceso está en Windows.
Los objetos con listas de control de acceso, como los objetos con nombre , incluidos archivos , claves de registro o incluso otros procesos y subprocesos , tienen una entrada en la Lista de control de acceso del sistema que rige el acceso a ellos, que define el nivel mínimo de integridad del proceso que puede utilizar el objeto. Windows se asegura de que un proceso pueda escribir o eliminar un objeto solo cuando su nivel de integridad sea igual o superior al nivel de integridad solicitado especificado por el objeto. [2] Además, por razones de privacidad, los objetos de proceso con un IL más alto están fuera de los límites para el acceso de lectura uniforme de los procesos con un IL más bajo. [3]
En consecuencia, un proceso no puede interactuar con otro proceso que tiene un IL más alto. Entonces, un proceso no puede realizar funciones como inyectar una DLL en un proceso de IL superior usando la CreateRemoteThread()
función [4] de la API de Windows o enviar datos a un proceso diferente usando la WriteProcessMemory()
función. [5]
Solicitud
Si bien los procesos heredan el nivel de integridad del proceso que lo generó, el nivel de integridad se puede personalizar en el momento de la creación del proceso. Además de definir el límite de los mensajes de ventana en la tecnología de aislamiento de privilegios de la interfaz de usuario (UIPI), aplicaciones como Adobe Reader , Google Chrome , Internet Explorer y Windows Explorer utilizan el control de integridad obligatorio para aislar los documentos de los objetos vulnerables del sistema. . [1]
Internet Explorer 7 presenta una configuración de "Modo protegido" basado en MIC para controlar si una página web se abre como un proceso de baja integridad o no (siempre que el sistema operativo admita MIC), según la configuración de la zona de seguridad, evitando así algunas clases de seguridad. vulnerabilidades. Dado que Internet Explorer en este caso se ejecuta como un proceso de bajo IL, no puede modificar los objetos a nivel del sistema; en cambio, las operaciones de archivo y registro se virtualizan. Adobe Reader 10 y Google Chrome son otras dos aplicaciones notables que están introduciendo la tecnología para reducir su vulnerabilidad al malware. [6]
Microsoft Office 2010 introdujo el entorno de espacio aislado "Vista protegida" para Excel, PowerPoint y Word que prohíbe que documentos potencialmente inseguros modifiquen componentes, archivos y otros recursos en un sistema. [7] La Vista protegida funciona como un proceso de baja integridad y, en Windows Vista y versiones posteriores de Windows, usa MIC y UIPI para restringir aún más la zona de pruebas. [8]
Sin embargo, en algunos casos, un proceso de IL superior necesita ejecutar ciertas funciones contra el proceso de IL inferior, o un proceso de IL inferior necesita acceder a recursos a los que solo un proceso de IL superior puede acceder (por ejemplo, cuando se visualiza una página web en modo protegido, guardar un archivo descargado de Internet en una carpeta especificada por el usuario). [1] Los procesos High IL y Low IL aún pueden comunicarse entre sí mediante el uso de archivos, canalizaciones con nombre , LPC u otros objetos compartidos. El objeto compartido debe tener un nivel de integridad tan bajo como el proceso Low IL y debe ser compartido por los procesos Low IL y High IL. [3] Dado que MIC no evita que un proceso de IL bajo comparta objetos con un proceso de IL superior, puede desencadenar fallas en el proceso de IL superior y hacer que funcione en nombre del proceso de IL bajo, provocando así un ataque de Squatting . [3] Los ataques Shatter , sin embargo, se pueden prevenir mediante el uso de User Interface Privilege Isolation que aprovecha MIC.
Ver también
- icacls
- Identificador de seguridad
- Control de acceso obligatorio
Referencias
- ^ a b c Matthew Conover. "Análisis del modelo de seguridad de Windows Vista" (PDF) . Symantec Corporation . Archivado desde el original (PDF) el 16 de mayo de 2008 . Consultado el 8 de octubre de 2007 .
- ^ a b Riley, Steve (22 de julio de 2006). "Control de integridad obligatorio en Windows Vista" . Archivo de Microsoft Docs . Microsoft .
- ^ a b c Russinovich, Mark (12 de febrero de 2007). "PsExec, Control de cuentas de usuario y límites de seguridad" . Archivo de blogs de Windows . Microsoft .
- ^ "Función CreateRemoteThread" . Centro de desarrollo de Windows . Microsoft . 5 de diciembre de 2018.
- ^ "Función WriteProcessMemory" . Centro de desarrollo de Windows . Microsoft . 5 de diciembre de 2018.
- ^ Brad Arkin (10 de julio de 2010). "Presentación del modo protegido de Adobe Reader" . Adobe Systems . Consultado el 10 de septiembre de 2010 .
- ^ "Planificar la configuración de Vista protegida para Office 2010" . Archivo de Microsoft Docs . Microsoft . 5 de agosto de 2011.
- ^ Keizer, Gregg (19 de agosto de 2009). "Microsoft destaca la seguridad 'sandbox' de Office 2010" . ComputerWorld . IDG . Consultado el 23 de enero de 2017 .
Otras lecturas
- "Referencia técnica del mecanismo de integridad de Windows Vista" . Archivo de Microsoft Docs . Microsoft . 5 de julio de 2007.
- "Introducción a la API del modo protegido" . Archivo de Microsoft Docs . Microsoft . 15 de agosto de 2007.
enlaces externos
- Introducción al control de integridad de Windows: artículo de enfoque de seguridad
- Escapar del Internet Explorer en modo protegido de Microsoft