Share via

Diseño del mecanismo de integridad de Windows

  • Artículo

El mecanismo de integridad de Windows es una extensión de la arquitectura de seguridad de Windows, que se basa en el Monitor de referencia de seguridad del kernel. El monitor de referencia de seguridad aplica el control de acceso comparando los SID de usuario y grupo en el token de acceso de seguridad con permisos de acceso concedidos en la ACL del descriptor de seguridad de un objeto. El mecanismo de integridad agrega un nivel de integridad al token de acceso de seguridad y una entrada de control de acceso de etiqueta obligatoria al ACL del sistema (SACL) en el descriptor de seguridad.

Las principales partes del mecanismo de integridad son:

  • Niveles de integridad predefinidos y su representación.
  • Directivas de integridad que restringen los permisos de acceso.
  • Nivel de integridad asignado al token de acceso de seguridad.
  • Entrada de control de acceso de etiqueta obligatoria.
  • Etiquetas obligatorias asignadas a objetos.
  • Restricciones de integridad dentro de las API AccessCheck y seAccessCheck en modo kernel.

Cada una de estas partes se describe con más detalle a continuación. El mecanismo de integridad de Windows siempre está en vigor, independientemente de otras opciones de directiva de seguridad. Las comprobaciones de nivel de integridad, como las comprobaciones de control de acceso, no son opcionales. No hay opciones de directiva de seguridad para deshabilitar las comprobaciones de nivel de integridad. Aunque el mecanismo de integridad admite UAC, el mecanismo de integridad permanece en vigor cuando UAC está deshabilitado por directiva de grupo de seguridad.

Niveles de integridad

Windows define los niveles de integridad mediante un SID. El uso de un SID para representar un nivel de integridad facilita la integración del mecanismo de integridad en estructuras de datos de seguridad existentes sin necesidad de cambios en el código. Los SID de nivel de integridad tienen la siguiente forma: S-1-16-xxxx. En la tabla 1 se muestran los componentes de los SID de nivel de integridad.

Tabla 1 Valores de entidad de certificación de identificador de SID de nivel de integridad

Value Descripción

16

Representa la entidad de etiqueta obligatoria (SECURITY_MANDATORY_LABEL_AUTHORITY).

xxxx

Representa el campo identificador relativo (RID) que es el nivel de integridad. El RID es un valor hexadecimal que representa el nivel de integridad.

Hay cuatro niveles de integridad principales en Windows Vista con cuatro valores correspondientes. Un valor inferior indica un nivel de integridad inferior o un nivel inferior de confiabilidad. Estos valores se definen en el archivo de encabezado winnt.h. En la tabla 2 se muestran los niveles de integridad definidos y sus valores correspondientes.

Tabla 2 Niveles de integridad definidos y valores correspondientes

Value Descripción Símbolo

0x0000

Nivel que no es de confianza

SECURITY_MANDATORY_UNTRUSTED_RID

0x1000

Nivel de integridad bajo

SECURITY_MANDATORY_LOW_RID

0x2000

Nivel de integridad media

SECURITY_MANDATORY_MEDIUM_RID

0x3000

Alto nivel de integridad

SECURITY_MANDATORY_HIGH_RID

0x4000

Nivel de integridad del sistema

SECURITY_MANDATORY_SYSTEM_RID

Un ejemplo de SID de nivel de integridad medio es esta cadena: S-1-16-8192. El valor rid de 8192 es el equivalente decimal de 0x2000.

Los RID están separados por intervalos de 0x1000 para permitir la definición de niveles adicionales en el futuro. La separación también permite asignar un nivel de integridad a un proceso ligeramente superior al medio: por ejemplo, para cumplir objetivos de diseño del sistema específicos.

Los SID de nivel de integridad definidos tienen valores de nombre de cadena asociados. El uso de la API LookupAccountSID devolverá nombres de cadena para cada SID de nivel de integridad. En la tabla 3 se muestran los nombres de cadena de los niveles de integridad.

Tabla 3 Nombres de cadena de nivel de integridad

SID de nivel de integridad Nombre

S-1-16-4096

Etiqueta obligatoria\Bajo nivel obligatorio

S-1-16-8192

Etiqueta obligatoria\Nivel obligatorio medio

S-1-16-12288

Etiqueta obligatoria\Alto nivel obligatorio

S-1-16-16384

Etiqueta obligatoria\Nivel obligatorio del sistema

Los niveles de integridad también se definen como cadenas SID en el Lenguaje de definición de descriptores de seguridad (SDDL). El SDDL define el formato de cadena que usan las funciones ConvertSecurityDescriptorToStringSecurityDescriptor y ConvertStringSecurityDescriptorToSecurityDescriptor para describir un descriptor de seguridad como una cadena de texto. El lenguaje también define elementos de cadena para describir información en los componentes de un descriptor de seguridad. El uso del SDDL para definir los niveles de integridad facilita la definición del nivel de integridad de un objeto cuando se crea el objeto. Para obtener más información sobre las cadenas de SID para los niveles de integridad, vea Recursos del mecanismo de integridad de Windows. La compatibilidad de SDDL con etiquetas obligatorias se describe en el Apéndice A: SDDL para etiquetas obligatorias.

Windows Vista usa SID de nivel de integridad en el token de acceso de seguridad para representar el nivel de integridad del sujeto y usa siD de nivel de integridad en la ace de etiqueta obligatoria en un descriptor de seguridad para representar el nivel de integridad del objeto.

Directivas de integridad

El mecanismo de integridad de Windows usa directivas sencillas para determinar cómo usar las etiquetas obligatorias en los objetos para restringir el nivel de acceso que está disponible para sujetos de menor integridad. Esto significa que las directivas limitan el tipo de acceso que los objetos de nivel de integridad inferior tienen permiso para tener objetos de nivel de integridad superior. En la tabla 4 se muestran las dos categorías de directiva.

Tabla 4 Categorías de directivas de integridad

Category Descripción

Directivas obligatorias del token de acceso

Establezca en el token de acceso y determine cómo se aplican las directivas obligatorias al asunto, que se representa en el token de acceso.

Directivas de etiquetas obligatorias

Establézcalo en la etiqueta obligatoria ACE (que se describe a continuación) en los objetos y determine cómo restringir el acceso al objeto.

Las directivas de integridad se usan cuando se realiza la comprobación de directivas obligatorias al evaluar los permisos de acceso en un objeto protegible. Las directivas determinan cómo se restringen los derechos de acceso entre niveles de integridad.

Directivas de token de acceso obligatorias

En la tabla 5 se muestran las directivas de token de acceso obligatorias definidas en Windows Vista.

Tabla 5 Directivas de token de acceso obligatorias en Windows Vista

Directiva Descripción

TOKEN_MANDATORY_NO_WRITE_UP

La directiva predeterminada que se asigna a todos los tokens de acceso. La directiva restringe el acceso de escritura de este sujeto a cualquier objeto en un nivel de integridad superior.

TOKEN_MANDATORY_NEW_PROCESS_MIN

Controla el comportamiento de asignar el nivel de integridad a los procesos secundarios. Normalmente, un proceso secundario hereda el nivel de integridad del proceso primario cuando el token de acceso del proceso primario se asigna al elemento secundario. Con la directiva NEW_PROCESS_MIN, el nivel de integridad del proceso secundario será el nivel de integridad mínimo del token de acceso primario o el nivel de integridad de objeto del archivo ejecutable para el nuevo proceso. Esta directiva se establece de forma predeterminada en todos los tokens de acceso.

La directiva NEW_PROCESS_MIN se puede describir mediante un ejemplo. Supongamos que hay un programa ejecutable denominado lowcalc.exe. Al archivo de programa se le asigna una etiqueta de integridad baja. Desde un símbolo del sistema, el usuario ejecuta lowcalc.exe. El proceso primario, cmd.exe, se ejecuta en un nivel de integridad medio. Dado que el archivo de imagen, lowcalc.exe, tiene una etiqueta de integridad baja, la directiva de NEW_PROCESS_MIN establece el nivel de integridad del nuevo proceso, lowcalc, en bajo. Esto se muestra en el ejemplo siguiente de la sección Diseño de aplicaciones para ejecutar en un nivel de integridad bajo.

Directivas de etiquetas obligatorias

Las directivas de etiqueta obligatorias se definen como marcas (bits) en el campo Máscara de la entrada de control de acceso de etiqueta obligatoria. Estas marcas de directiva determinan las restricciones de los permisos de acceso que se aplican a los sujetos de integridad inferiores. En la tabla 6 se muestran las directivas de etiqueta obligatorias definidas en Windows Vista.

Tabla 6 Directivas de etiqueta obligatorias en Windows Vista

Directiva Descripción

SYSTEM_MANDATORY_POLICY_NO_WRITE_UP

La directiva predeterminada en todas las etiquetas obligatorias del objeto. La marca es equivalente a la directiva de token de acceso de NO_WRITE_UP. La directiva restringe el acceso de escritura al objeto por un sujeto con un nivel de integridad inferior.

SYSTEM_MANDATORY_POLICY_NO_READ_UP

Restringe el acceso de lectura al objeto por un sujeto con un nivel de integridad inferior. La directiva se usa, por ejemplo, para restringir el acceso de lectura al espacio de direcciones de memoria virtual de un proceso.

SYSTEM_MANDATORY_POLICY_NO_EXECUTE_UP

Restringe el acceso de ejecución al objeto por un sujeto con un nivel de integridad inferior. La directiva se usa, por ejemplo, para restringir los permisos de activación de inicio en una clase COM por sujetos de integridad inferior.

Estas directivas definidas cumplen los objetivos de diseño de Windows Vista. La arquitectura del mecanismo de integridad permite la expansión futura mediante la definición de opciones de directiva adicionales que controlan los permisos de acceso entre sujetos y objetos en distintos niveles de integridad.

Cómo se asignan las directivas de integridad a derechos genéricos

La comprobación de directiva obligatoria se produce como parte de la función de seguridad AccessCheck. AccessCheck (y SeAccessCheck en modo kernel) tiene como uno de los parámetros de función una estructura GENERIC_MAPPING. La asignación genérica proporcionada por el autor de la llamada asigna derechos de acceso específicos del objeto a las categorías genéricas de lectura, escritura y ejecución. Las directivas de etiquetas obligatorias implementan restricciones en el acceso permitido en función de las categorías genéricas. Para un tipo de objeto determinado, el GENERIC_MAPPING se comunica con la directiva obligatoria para comprobar qué derechos de acceso específicos están prohibidos.

Si la estructura de GENERIC_MAPPING que se pasa a una llamada a AccessCheck es ceros (0), la asignación genérica no está definida. Cuando la asignación genérica no está definida, la comprobación de directiva obligatoria restringe todos los derechos de acceso por sujetos de integridad inferior. Los administradores de recursos que usan AccessCheck para la seguridad de objetos privados y pasan una estructura de GENERIC_MAPPING de todos los ceros verán errores de acceso denegado . Se requiere un cambio de código en la aplicación de Resource Manager para asignar derechos de acceso específicos del tipo de objeto a los derechos de acceso genéricos que exige la directiva obligatoria.

Cómo se asignan los niveles de integridad a los tokens de acceso

El token de acceso de seguridad es una estructura de datos interna que usa el kernel. El token de acceso de seguridad contiene valores de información diferentes que corresponden a privilegios, pertenencia a grupos y otros detalles relacionados con la seguridad. La inicialización del token de acceso se produce cuando un usuario inicia sesión interactivamente en Windows o cuando se produce una autenticación de red. Cuando se inicializa el token de acceso, se agregan el SID del usuario, los SID de grupo y los privilegios, además de otros valores. Windows Vista asigna el nivel de integridad del token de acceso cuando se inicializa el token de acceso.

El kernel asigna un token de acceso a todos los procesos y subprocesos. El token de acceso principal del proceso contiene el nivel de integridad asociado a ese proceso. En el mecanismo de integridad de Windows, el nivel de integridad del proceso se conoce como el nivel de integridad del sujeto. Si el token de acceso de una aplicación contiene el SID de integridad media, el proceso de aplicación se ejecuta en un nivel de integridad media. A varios procesos de aplicación que se ejecutan en la misma cuenta de usuario se les asigna el mismo token de acceso principal. Así es como se asigna a cada una de las aplicaciones el mismo nivel de integridad.

Los niveles de integridad se asignan a los tokens de acceso en función de siD de grupo específicos que están presentes en la estructura de TOKEN_GROUPS. El kernel de Windows asigna un nivel de integridad basado en cuentas de grupo o usuario integradas específicas. Windows Vista asigna un token de acceso que tiene el SID de cuenta de sistema local presente el nivel de integridad del sistema, se asigna un token de acceso con el SID del grupo de administradores local presente el nivel de integridad de alto y se asigna un token de acceso para una cuenta de usuario estándar al nivel de integridad de medio.

En la tabla 7 se muestran las asignaciones de nivel de integridad al token de acceso, en función de la presencia de SID específicos.

Tabla 7 Niveles de integridad vinculados a SID específicos

SID en el token de acceso Nivel de integridad asignada

LocalSystem (Sistema local)

Sistema

LocalService (Servicio local)

Sistema

NetworkService (Servicio de red)

Sistema

Administradores

Alto

Operadores de copias de seguridad

Alto

Operadores de configuración de red

Alto

Operadores criptográficos

Alto

Usuarios autenticados

Media

Todos (Mundo)

Bajo

Anónima

No es de confianza

Los niveles de integridad definen diferentes niveles de confiabilidad para las aplicaciones que se ejecutan en diferentes niveles de acceso. La mayoría de las aplicaciones de Windows Vista se ejecutan en un nivel de acceso de usuario estándar en el nivel de integridad media. Las aplicaciones en el nivel de integridad media no experimentan ninguna restricción sobre cómo interactúan con otras aplicaciones y con datos en el nivel de integridad media. Tareas o aplicaciones específicas que requieren derechos administrativos que se ejecutan en un nivel de integridad alto. Los servicios del sistema se ejecutan en el nivel de integridad del sistema, ya que hay restricciones en su capacidad de interactuar con el escritorio predeterminado y a menudo se ejecutan con privilegios eficaces del sistema. Algunas aplicaciones que se han diseñado para ejecutarse con los derechos más mínimos posibles, como el modo protegido de Internet Explorer, se pueden ejecutar con un nivel de integridad bajo.

Algunos privilegios administrativos de Windows se pueden asignar a un token de acceso solo con al menos un nivel de integridad alto. Si el nivel de integridad del token de acceso es menor que alto, no se permiten privilegios administrativos específicos y se quitan del token de acceso. Los privilegios administrativos asociados a un nivel de integridad alto son:

  • SE_CREATE_TOKEN_PRIVILEGE
  • SE_TCB_PRIVILEGE
  • SE_TAKE_OWNERSHIP_PRIVILEGE
  • SE_BACKUP_PRIVILEGE
  • SE_RESTORE_PRIVILEGE
  • SE_DEBUG_PRIVILEGE
  • SE_IMPERSONATE_PRIVILEGE
  • SE_RELABEL_PRIVILEGE
  • SE_LOAD_DRIVER_PRIVILEGE

Las aplicaciones pueden asignar un nivel de integridad bajo a un token de acceso duplicado al crear un proceso secundario. Windows puede ejecutar un proceso de aplicación con un nivel de integridad bajo si el archivo de imagen del programa ejecutable tiene una etiqueta obligatoria baja. Estas características se describen más adelante en este artículo.

Obtención del nivel de integridad de un token de acceso

El nivel de integridad se almacena en el token de acceso mediante el campo TOKEN_GROUPS. La estructura TOKEN_GROUPS es una lista de SID y atributos que identifican las pertenencias a grupos de esa cuenta de usuario. El nivel de integridad del token de acceso también se identifica en la lista de grupos mediante un atributo SID. La estructura SID_AND_ATTRIBUTES contiene el SID de nivel de integridad y el nivel de integridad se identifica mediante los atributos SE_GROUP_INTEGRITY y SE_GROUP_INTEGRITY_ENABLED.

Puede recuperar el nivel de integridad del token de acceso del token de acceso mediante la API GetTokenInformation. GetTokenInformation tiene un parámetro para indicar qué clase de información de token de acceso se va a recuperar. El parámetro TOKEN_INFORMATION_CLASS tiene un valor definido para el nivel de integridad, TokenIntegrityLevel. La estructura de datos devuelta es un tipo TOKEN_MANDATORY_LABEL.

Para determinar el nivel de integridad de un proceso

  1. Abra un identificador para el token de acceso del proceso.

  2. Obtenga el nivel de integridad del token de acceso.

  3. Compare el SID de nivel de integridad con los IDENTIFICADORes de nivel de integridad definidos por el sistema.

El código de ejemplo para obtener el nivel de integridad del token de acceso se muestra en el Apéndice D.

Visualización del nivel de integridad de un token de acceso

El nivel de integridad del token de acceso de seguridad de un proceso se puede ver mediante herramientas que exponen los detalles de seguridad de un proceso, como el Explorador de procesos de SysInternals.com. Las imágenes siguientes muestran la presentación del Explorador de procesos con la columna Nivel de integridad agregada a la vista (a la derecha).

Figura 1 Nivel de integridad en el Explorador de procesos

Si observamos las propiedades de seguridad de un proceso específico, como explorer.exe, el Explorador de procesos muestra el nivel de integridad en la lista de grupos definidos en el token de acceso de seguridad del proceso. En la imagen siguiente se muestra el nivel obligatorio etiqueta/medio obligatorio asignado al token de acceso para el proceso, explorer.exe.

Figura 2 Explorer.exe como un proceso de nivel de integridad medio

Establecimiento del nivel de integridad de un token de acceso

Por lo general, las aplicaciones no necesitan cambiar el valor del nivel de integridad del proceso. Normalmente, las aplicaciones no necesitan realizar cambios en ninguno de los valores del token de acceso de seguridad. Sin embargo, en algunas circunstancias, los servicios que admiten clientes locales en distintos niveles de integridad pueden optar por llevar a cabo tareas en un nivel de integridad inferior. La suplantación es una manera de que un subproceso de servicio se ejecute en un nivel de integridad inferior. Cuando un subproceso de servicio suplanta a un cliente local, el subproceso de suplantación tiene el contexto de seguridad del cliente, que incluye el nivel de integridad del cliente si el cliente se ejecuta en la misma máquina local.

Otra manera de que una aplicación pueda realizar una operación, como crear un conjunto de archivos y claves del Registro, en un nivel de integridad inferior es establecer tokenIntegrityLevel para el token de acceso del subproceso actual. El nuevo nivel de integridad no puede ser mayor que el nivel de integridad del token de acceso principal del proceso.

Para establecer el valor de un nivel de integridad de token de acceso en un subproceso

  1. Llame a OpenThreadToken para obtener un identificador del token de acceso.

  2. Llame a GetTokenInformation con el valor del parámetro TOKEN_INFORMATION_CLASS de TokenIntegrityLevel para guardar el nivel de integridad del subproceso actual.

  3. Llame a SetTokenInformation con el valor del parámetro TOKEN_INFORMATION_CLASS de TokenIntegrityLevel.

Dado que no hay ningún límite de seguridad dentro de un espacio de direcciones de proceso entre subprocesos en distintos niveles de integridad, los diseñadores de aplicaciones deben tener en cuenta los posibles riesgos de seguridad de tener código ejecutándose en un subproceso con una integridad inferior que se ejecute en un proceso de mayor integridad. La mayoría de las aplicaciones pueden resultar más fáciles de crear un proceso independiente que se ejecute en el nivel de integridad inferior para realizar tareas de menor integridad.

Se muestra un ejemplo de cómo establecer TokenIntegrityLevel y crear un proceso en un nivel de integridad inferior en Cómo establecer el nivel de integridad de un token de acceso.

ACE de etiqueta obligatoria

El mecanismo de integridad de Windows define un nuevo tipo ACE, la etiqueta obligatoria del sistema ACE. La ACE de etiqueta obligatoria se usa para representar la etiqueta obligatoria de un objeto en el descriptor de seguridad del objeto. La etiqueta obligatoria contiene el nivel de integridad y la directiva de integridad asociada. Una ace de etiqueta obligatoria solo se usa en la ACL del sistema, o SACL, del descriptor de seguridad. SACL es un campo independiente en el descriptor de seguridad de la ACL discrecional (DACL).

Figura 3 Campos de descriptor de seguridad

La ACL discrecional contiene permisos de acceso de usuario y grupo al objeto. Cualquier usuario o grupo puede realizar actualizaciones en la DACL con WRITE_DAC permisos de acceso a objetos. Las ACL discrecionales se pueden actualizar con más frecuencia y por diferentes usuarios. Uno de los objetivos de diseño del mecanismo de integridad es que el sistema de seguridad debe mantener la etiqueta con un objeto después de aplicar una etiqueta obligatoria al objeto. La aplicación de la etiqueta obligatoria adecuada en el descriptor de seguridad de objetos, con poco o ningún impacto en las aplicaciones diseñadas para administrar las ACL, se logra colocando la etiqueta obligatoria en la ACL del sistema, donde se encuentra principalmente bajo el control del sistema de seguridad. La etiqueta obligatoria es lógicamente independiente de las entradas de auditoría del sistema en sacl. No hay ningún orden necesario para que la etiqueta obligatoria preceda o siga las entradas de auditoría del sistema en la SACL.

La ACE de etiqueta obligatoria es similar a una ACE de acceso permitida, en que contiene un encabezado ACE, una máscara de acceso y un SID. La parte del SID de la etiqueta obligatoria ACE contiene el SID de nivel de integridad. En la tabla 8 se muestran los campos del encabezado ACE.

Tabla 8 Campos contenidos en el encabezado ACE

Campo de encabezado ACE Value

AceType

SYSTEM_MANDATORY_LABEL_ACE_TYPE

AceFlags

Marcas de control que definen la herencia del tipo ACE de etiqueta obligatoria

AceSize

Tamaño de la ACE de etiqueta obligatoria

La etiqueta obligatoria ACE contiene un campo Máscara . La máscara se usa para definir las directivas obligatorias que determinan las restricciones de los permisos de acceso que se aplican a procesos (o sujetos) con un nivel de integridad inferior. Una directiva de ejemplo que se usa ampliamente en Windows Vista es la directiva de NO_WRITE_UP. La marca de directiva NO_WRITE_UP en la máscara ACE de etiqueta obligatoria significa que los sujetos con un nivel de integridad inferior (en el token de acceso) que el SID de nivel de integridad en la etiqueta obligatoria del objeto están restringidos a obtener acceso de escritura genérico al objeto.

Solo hay una etiqueta obligatoria efectiva en un objeto . Si se produce que un descriptor de seguridad obtenga más de una etiqueta obligatoria en la SACL, la primera etiqueta obligatoria ACE en la SACL es la etiqueta efectiva para el objeto.

Para obtener más información sobre la ace de etiqueta obligatoria, consulta Recursos del mecanismo de integridad de Windows.

Lectura de la ace de etiqueta obligatoria

Windows Vista usa la función de seguridad GetSecurityInfo para leer la información de etiqueta obligatoria de un objeto. GetSecurityInfo obtiene la información de propietario, grupo, DACL o SACL de un objeto. El parámetro SECURITY_INFORMATION a GetSecurityInfo determina qué parte del descriptor de seguridad se devuelve. Windows Vista define un nuevo valor de información de seguridad, LABEL_SECURITY_INFORMATION, que se usa para devolver la etiqueta obligatoria ACE de SACL. Si la llamada a GetSecurityInfo especifica SACL_SECURITY_INFORMATION, solo se devuelven las ACE de auditoría del sistema en la SACL, no la ACE de etiqueta obligatoria.

El permiso de acceso necesario para leer la ACE de etiqueta obligatoria en un objeto es el derecho de acceso estándar READ_CONTROL. Normalmente, el derecho de acceso ACCESS_SYSTEM_SECURITY es necesario para obtener o establecer información en la SACL. ACCESS_SYSTEM_SECURITY solo se concede si el privilegio SE_SECURITY_NAME está habilitado en el token de acceso. La lectura de la etiqueta obligatoria de SACL no requiere SE_SECURITY_NAME privilegio ni el derecho de acceso ACCESS_SYSTEM_SECURITY.

Establecimiento de la etiqueta OBLIGATORIA ACE

Windows Vista usa la función de seguridad SetSecurityInfo para cambiar la información de etiqueta obligatoria en un objeto. El subsistema de seguridad establece la etiqueta obligatoria del objeto cuando se crea el objeto. El parámetro SECURITY_INFORMATION a SetSecurityInfo debe incluir LABEL_SECURITY_INFORMATION para cambiar la etiqueta obligatoria en el descriptor de seguridad.

La etiqueta obligatoria que se asigna en la creación de objetos suele ser el nivel de integridad correcto para un objeto y no es necesario cambiar la etiqueta obligatoria. Sin embargo, puede haber requisitos de diseño de aplicaciones para cambiar el nivel de integridad de un objeto cuando la aplicación está diseñada para admitir varios procesos cliente en distintos niveles de integridad.

Los permisos necesarios para cambiar la ace de etiqueta obligatoria en la SACL de un descriptor de seguridad se WRITE_OWNER. La escritura de la etiqueta obligatoria en la SACL no requiere privilegios SE_SECURITY_NAME ni el derecho de acceso ACCESS_SYSTEM_SECURITY. El nivel de integridad de la etiqueta obligatoria se puede establecer en un valor menor o igual que el nivel de integridad del sujeto.

El cambio más común es reducir el nivel de integridad de un objeto para permitir que un proceso de aplicación de integridad inferior tenga acceso de modificación. Por ejemplo, una aplicación en el nivel de integridad media debe sincronizarse con otro proceso de aplicación que se ejecuta en un nivel de integridad bajo. El proceso de integridad media crea un objeto de exclusión mutua con nombre y lo asigna una etiqueta obligatoria en un nivel bajo para permitir que un proceso de integridad inferior abra la exclusión mutua en eventos de señal.

Privilegio de cambio de etiqueta

El mecanismo de integridad de Windows define un nuevo privilegio de seguridad de Windows, SE_RELABEL_NAME. Cuando se habilita en un token de acceso de seguridad, el privilegio de seguridad de cambio de etiqueta permite al sujeto establecer la etiqueta obligatoria de un objeto en un nivel de integridad mayor que el nivel de integridad del token de acceso del sujeto. La directiva de seguridad predeterminada para Windows Vista no asigna este privilegio a ningún usuario o grupo. El privilegio está diseñado para abordar escenarios en los que un proceso de administrador que se ejecuta en un nivel de integridad alto debe cambiar o asignar la etiqueta obligatoria para los objetos en el nivel de integridad del sistema. Windows Vista no tiene ninguna tarea que requiera o use el privilegio de cambio de etiqueta.

Cómo Asigna Windows una etiqueta obligatoria a los objetos

Windows asigna una etiqueta obligatoria a un objeto protegible cuando se crea el descriptor de seguridad del objeto. El nivel de integridad de un nuevo objeto se asigna de una de estas tres maneras:

  • El subsistema de seguridad asigna al objeto una etiqueta obligatoria cuando se crea el descriptor de seguridad para el objeto.
  • El proceso de creación especifica una etiqueta obligatoria explícita como atributos de seguridad al crear el objeto mediante una función, como CreateFile.
  • El contenedor primario define una ACE de etiqueta obligatoria que se puede heredar que se aplica a los objetos secundarios que se crean en el contenedor.

La manera más fácil de comprender cómo se asignan los niveles de integridad de objetos es suponer que a cada objeto se le asigna una etiqueta obligatoria con el mismo nivel de integridad que el nivel de integridad del sujeto del proceso de creación (o subproceso). Sin embargo, hay excepciones a la idea general basada en el tipo de objeto y el nivel de integridad del sujeto. Las excepciones son el resultado de las opciones de diseño necesarias para admitir otros requisitos del sistema para una experiencia de usuario coherente cuando varias directivas de seguridad, como UAC, están habilitadas o deshabilitadas.

Las etiquetas obligatorias se pueden aplicar a todos los objetos protegibles que tienen control de acceso basado en el descriptor de seguridad. Hay muchos tipos de objetos protegibles, incluidos los objetos process y thread, los objetos con nombre y los objetos persistentes, como archivos o claves del Registro. Windows Vista no asigna etiquetas obligatorias explícitas a todos los tipos de objeto cuando se crean objetos. Los tipos de objeto a los que el subsistema de seguridad asigna etiquetas obligatorias en la creación de objetos son:

  • Proceso
  • Thread
  • Access token
  • Trabajo

Todos los demás tipos de objeto tienen un valor predeterminado implícito o una etiqueta obligatoria heredada. Recuerde que, durante la inicialización del token de acceso, se asigna un nivel de integridad al token de acceso de seguridad que se crea durante un inicio de sesión interactivo. El primer proceso que se inicia en nombre de un inicio de sesión de usuario es userinit.exe, que inicia el proceso de shell, explorer.exe. Userinit.exe inicia un servicio del sistema (Winlogon) que usa una llamada a CreateProcessAsUser y pasa el token de acceso para el usuario de inicio de sesión interactivo.

CreateProcessAsUser crea un objeto de proceso y un subproceso inicial, entre otras cosas. Cuando se crea el objeto de proceso, el descriptor de seguridad de ese proceso se asigna al nivel de integridad del token de acceso que se asigna como token de acceso principal al nuevo proceso. Cuando userinit.exe llama a CreateProcess para iniciar el shell, se inicializa el objeto de proceso para explorer.exe. El objeto de proceso incluye un descriptor de seguridad y un token de acceso principal. La etiqueta obligatoria del proceso de explorer.exe se establece en el nivel de integridad del proceso de creación, userinit.exe, que es medio. El token de acceso principal para explorer.exe se hereda del proceso primario de creación, userinit.exe y tiene un nivel de integridad de medio. Cuando el proceso de explorer.exe crea un nuevo subproceso, el objeto de subproceso recibe un descriptor de seguridad y el subsistema de seguridad asigna un nivel de integridad al objeto de subproceso en función del nivel de integridad del proceso de creación. A los objetos de subproceso del proceso de explorer.exe se les asigna un nivel de integridad de medio, que es el nivel de integridad del token de acceso principal del proceso de creación.

Nota

Un objeto de token de acceso es un objeto protegible con su propio descriptor de seguridad. El descriptor de seguridad del token se usa para determinar el acceso permitido durante las funciones OpenProcessToken o OpenThreadToken. El objeto de token de acceso tiene una etiqueta obligatoria en el descriptor de seguridad en el objeto de token de acceso. El token de acceso también contiene un SID de nivel de integridad en la lista de grupos de tokens de acceso que representa el nivel de integridad del sujeto.

Al asignar siempre etiquetas obligatorias para procesar, subprocesar, token y objetos de trabajo, el mecanismo de integridad impide que los procesos del mismo usuario en niveles de integridad inferiores accedan a estos tipos de objeto y modifiquen su contenido o comportamiento, como insertar un archivo DLL o suplantar un token de acceso de nivel superior.

Nivel de integridad predeterminado

No todos los tipos de objeto se asignan a una ACE de etiqueta obligatoria en el descriptor de seguridad. Si hay una ACE de etiqueta obligatoria en el descriptor de seguridad, se denomina etiqueta obligatoria explícita. Si no hay ninguna ACE de etiqueta obligatoria, el subsistema de seguridad usa una etiqueta obligatoria predeterminada implícita para ese objeto durante la comprobación de directiva obligatoria. La etiqueta obligatoria predeterminada asigna un nivel de integridad medio para todos los objetos protegibles. Si no se define una etiqueta obligatoria en el descriptor de seguridad, la etiqueta obligatoria predeterminada implícita se aplica a todos los tipos de objetos.

El nivel de integridad de objeto predeterminado de medio, combinado con la directiva obligatoria predeterminada de NO_WRITE_UP, restringe el acceso de modificación a todos los objetos por procesos con un nivel de integridad de sujeto menor que medio. La etiqueta y la directiva obligatorias predeterminadas impiden que los procesos no confiables en una integridad baja modifiquen los archivos de usuario o del sistema o las claves del Registro en el sistema que, de lo contrario, puedan permitir el acceso de escritura discrecional en la DACL.

Los objetos del sistema de archivos NTFS y las claves del Registro no se etiquetan automáticamente cuando se crean. Estos objetos no tienen etiquetas obligatorias después de la actualización de una versión anterior de Windows a Windows Vista. Los archivos de sistemas de archivos que no son NTFS (CDFS o FAT32) que no tienen descriptores de seguridad no son objetos protegibles y no tienen un nivel de integridad. Cada descriptor de seguridad debe tener una etiqueta obligatoria implícita.

Los procesos con un nivel de integridad de sujeto en el medio o superior crean archivos y claves del Registro sin una etiqueta explícita. Como consecuencia, el sistema de archivos y los objetos del Registro creados por un proceso de nivel alto o de integridad del sistema tienen una etiqueta media implícita. Las aplicaciones que usan etiquetas obligatorias pueden definir etiquetas explícitas al crear objetos. Sin embargo, Windows Vista no asigna etiquetas más altas que el nivel de integridad media al sistema de archivos o al registro de forma predeterminada. Esto no significa que estos objetos estén necesariamente abiertos a la modificación mediante procesos de integridad inferior. La lista de control de acceso discrecional heredado (o predeterminado) en el sistema de archivos o los objetos del Registro creados por un proceso de alto nivel o de sistema concede acceso de escritura solo a los miembros del grupo Administradores o a las cuentas de servicio o sistema locales.

Varias restricciones de diseño necesarias con la etiqueta obligatoria implícita predeterminada de medio, en lugar de asignar una etiqueta obligatoria explícita basada en el nivel de integridad del sujeto para la mayoría de los tipos de objetos. Un ejemplo específico se basa en la capacidad de habilitar o deshabilitar el control de cuentas de usuario mediante la directiva de seguridad local. Cuando UAC está deshabilitado, un usuario que es miembro del grupo de administradores local tiene todos los procesos que se ejecutan con un token de acceso con privilegios completo en un nivel de integridad alto. Si todos los objetos se etiquetan explícitamente en el nivel de integridad del sujeto, todos los archivos, como documentos y hojas de cálculo que crea el usuario, se asignarían un nivel de integridad alto. La etiqueta alta parece adecuada, aunque los permisos DACL heredados para el perfil de usuario proporcionen un control de acceso suficiente para el acceso de usuario. Sin embargo, si el equipo local o directiva de grupo habilita UAC, a la mayoría de los procesos ejecutados por el mismo usuario se les asigna un token de acceso de seguridad filtrado en un nivel de integridad medio. Después de habilitar UAC, el usuario no podrá abrir archivos creados cuando UAC se deshabilitó. Una aplicación de integridad media que intentó abrir los documentos de alta integridad del usuario recibiría un error de acceso denegado.

Si un proceso se ejecuta con un nivel de integridad de sujeto menor que el nivel de integridad predeterminado de medio, ese proceso tendrá permisos de acceso restringidos a todos los objetos que tienen un nivel de integridad medio implícito. Los procesos con un nivel de integridad bajo no podrán modificar ningún objeto con un nivel de integridad explícito o implícito de medio o superior, independientemente de los derechos de acceso concedidos en la DACL a la entidad de seguridad. Por lo tanto, todos los objetos creados por un proceso con un nivel de integridad de sujeto menor que el nivel predeterminado (medio) se etiquetan explícitamente mediante el subsistema de seguridad. Las restricciones de acceso en procesos de integridad baja son posibles en Windows Vista porque todas las aplicaciones se ejecutan normalmente en el nivel de integridad media y los problemas de compatibilidad de aplicaciones son mínimos. Las aplicaciones que se ejecutan correctamente en una integridad baja suelen requerir cambios de diseño específicos para funcionar correctamente con acceso restringido. Los cambios de diseño se describen en la sección siguiente sobre el diseño de aplicaciones para ejecutarse en un nivel de integridad bajo.

Etiquetado de objetos creados por sujetos bajos

Las aplicaciones se pueden iniciar mediante la función CreateProcessAsUser en un nivel de integridad bajo. CreateProcessAsUser inicializa un proceso bajo con la siguiente información de nivel de integridad:

  • El nuevo objeto de proceso se crea con un descriptor de seguridad que contiene una etiqueta obligatoria con una integridad baja.
  • Se crea un nuevo objeto de subproceso para ese proceso y con un descriptor de seguridad que contiene una etiqueta obligatoria con una integridad baja.
  • Se asigna un token de acceso principal al nuevo proceso. El objeto de token de acceso tiene un descriptor de seguridad con una etiqueta obligatoria en un nivel bajo y el token de acceso contiene un TokenIntegrityLevel con un SID de integridad baja que representa el nivel de integridad del sujeto.

Supongamos que el proceso de integridad baja se está ejecutando y que quiere crear un subproceso. Para crear un subproceso, debe abrir su propio objeto de proceso para el acceso de escritura para crear un nuevo objeto de subproceso. Si la etiqueta obligatoria en el objeto de proceso fuera media, el asunto bajo no podría abrir el proceso y no podría crear un subproceso nuevo. Dado que el objeto de proceso también está etiquetado con una integridad baja, el sujeto bajo puede abrir el proceso para el acceso de escritura y crear un nuevo objeto de subproceso. En el ejemplo se muestra por qué es importante que las etiquetas obligatorias en el objeto de proceso, los objetos de subproceso y el token de acceso de seguridad sean coherentes en el mismo nivel de integridad.

Nota

Esto se aplica a todos los niveles de integridad, no solo sujetos bajos.

Supongamos que el proceso bajo crea un archivo temporal. La aplicación llama a CreateFile para crear un nuevo archivo, escribir algunos datos y cerrar el archivo. Más adelante, el proceso bajo quiere volver a abrir el mismo archivo para anexar datos. Si el archivo temporal tiene una etiqueta obligatoria predeterminada implícita en el nivel de integridad media, el proceso bajo no podrá volver a abrir el archivo que creó anteriormente para modificar el acceso. Podría surgir el mismo problema para cualquier objeto protegible que un sujeto con un nivel de integridad por debajo del nivel predeterminado de medio crea. Por lo tanto, a todos los objetos protegibles creados por un sujeto con un nivel de integridad por debajo del nivel predeterminado se les asigna automáticamente una etiqueta obligatoria explícita. En otras palabras, todos los objetos kernel, las claves del Registro y los objetos del sistema de archivos se etiquetan explícitamente en un nivel bajo cuando el nivel de integridad del sujeto es bajo.

Creación de un objeto con una etiqueta obligatoria específica

La mayoría de las aplicaciones de Windows no necesitan ser "compatibles con la integridad". El subsistema de seguridad crea automáticamente objetos y los asigna una etiqueta obligatoria. Dado que la mayoría de las aplicaciones se ejecutan en un nivel de integridad medio y el nivel de integridad de objeto predeterminado es medio, la directiva de integridad no cambia el control de acceso permitido para la mayoría de las aplicaciones. Sin embargo, algunas aplicaciones, como los servicios, están diseñadas para admitir aplicaciones cliente en distintos niveles de integridad. Es posible que el servicio se ejecute en un nivel de integridad mayor que el cliente y quiera etiquetar nuevos objetos creados en nombre del cliente explícitamente en un nivel de integridad inferior. El proceso de creación puede establecer el nivel de integridad del objeto. La restricción es que el nivel de integridad del nuevo objeto debe ser menor o igual que el nivel de integridad del proceso de creación.

Para crear un objeto con una etiqueta obligatoria específica
  1. Cree un descriptor de seguridad sdDL que defina una etiqueta obligatoria baja, por ejemplo:
    #define LOW_INTEGRITY_SDDL_SACL_W L"S:(ML;;NW;;;LW)"
  2. Convierta la cadena SDDL en un descriptor de seguridad mediante ConvertStringSecurityDescriptorToSecurityDescriptor.
  3. Asigne el descriptor de seguridad con la etiqueta obligatoria baja a una estructura de atributos de seguridad.
  4. Pase el parámetro de atributos de seguridad a la llamada para crear un objeto, como CreateFile.

Herencia de etiquetas obligatorias

Windows Vista no etiqueta explícitamente archivos y directorios en el sistema de archivos NTFS. Como se mencionó anteriormente, el subsistema de seguridad usa una etiqueta obligatoria implícita con un nivel predeterminado de medio para los objetos que no tienen una etiqueta obligatoria en el descriptor de seguridad.

Las aplicaciones se pueden diseñar para ejecutarse en un nivel de integridad bajo. Modo protegido Internet Explorer es un ejemplo de una aplicación de Windows Vista diseñada para ejecutarse con integridad baja. Las aplicaciones con integridad baja pueden necesitar carpetas en el sistema de archivos donde pueden escribir archivos temporales o datos de aplicación. En el caso del modo protegido Internet Explorer, se usa la carpeta Archivo de Internet temporal del perfil del usuario. ¿Cómo puede una aplicación baja escribir en una carpeta del sistema de archivos? A la carpeta se le debe asignar una etiqueta obligatoria explícita que permita el acceso de escritura desde un proceso de integridad baja.

Según el diseño de la aplicación, puede haber otros procesos de cooperación que agreguen archivos a la carpeta utilizada por la aplicación de integridad baja. Si los demás procesos también se ejecutan con poca integridad, los archivos creados por esos procesos se asignan automáticamente a una etiqueta obligatoria baja. Sin embargo, si el otro proceso de asociado tiene una integridad mayor, el proceso de asociado (un servicio de sincronización de archivos o un agente de usuario) podría crear archivos en la carpeta baja que no se etiquetan automáticamente en un nivel bajo. El proceso de asociado crea un archivo medio en la carpeta usada por la aplicación baja, que la aplicación baja no puede modificar ni eliminar.

El mecanismo de integridad permite que una carpeta con una etiqueta obligatoria baja tenga objetos secundarios, archivos y subcarpetas, cada una con una etiqueta obligatoria diferente y superior porque cada objeto del sistema de archivos tiene un descriptor de seguridad único. Hay muchos escenarios en los que la intención es que, para una carpeta que tenga asignada una etiqueta obligatoria baja, a todos los archivos de la carpeta se les debe asignar una etiqueta obligatoria baja para que un proceso bajo pueda modificarlos. El mecanismo de integridad lo admite al permitir que los ASE de etiqueta obligatoria se puedan heredar del contenedor primario a los subcontenementos y objetos secundarios.

La estructura de datos de tipo ACE de etiqueta obligatoria contiene un encabezado ACE con un campo AceFlags. El campo AceFlags se usa para definir marcas de herencia para el tipo ACE que son iguales que las marcas de herencia para otros tipos ace, como el tipo ace permitido de access que se usa para el acceso discrecional. Las ACE de etiqueta obligatoria se pueden definir como heredables, para la herencia de contenedor (CI) o como herencia de objeto (OI). Las ACE de etiqueta obligatoria no se pueden inherit_only (E/S). Si hay una ACE obligatoria heredable asignada a un contenedor, la etiqueta obligatoria se aplica al propio contenedor y a los objetos secundarios para los que se aplica la herencia.

Un ejemplo de una etiqueta obligatoria heredable es la etiqueta obligatoria baja en una de las carpetas creadas en cada perfil de usuario: %USERPROFILE%\AppData\LocalLow. A esta carpeta se le asigna una etiqueta obligatoria baja cuando se inicializa el perfil y se pretende como la carpeta de nivel superior que se puede escribir de forma predeterminada en las aplicaciones de baja integridad. En la imagen siguiente se muestra la etiqueta obligatoria heredable en la carpeta AppData\LocalLow que se muestra mediante el comando Icacls. Para obtener más información sobre cómo Icacls admite etiquetas obligatorias, consulte apéndice B: Icacls y niveles de integridad de archivos.

Las marcas de herencia de la etiqueta obligatoria indican que la ACE es (OI) y (CI) ACE con una directiva obligatoria de NO_WRITE_UP (NW). Todas las subcarpetas que se crean en la carpeta AppData\LocalLow heredarán la etiqueta que se puede heredar.

Figura 4 Etiqueta obligatoria baja heredable

Cuando se crea un nuevo archivo o subcarpeta a partir de un proceso medio, el nuevo objeto hereda la etiqueta obligatoria baja. En el ejemplo siguiente, el símbolo del sistema se ejecuta en proceso con un nivel de integridad medio. Se crea un archivo, newfile.txt y una nueva carpeta, Temp, en la carpeta LocalLow y ambos objetos heredan la etiqueta obligatoria baja del contenedor primario. Icacls indica que la etiqueta obligatoria se hereda con la designación (I).

Figura 5 Heredar una etiqueta obligatoria en un objeto secundario

La herencia de etiquetas obligatorias garantiza la coherencia en el nivel de integridad de los objetos que se crean en una parte del espacio de nombres del sistema de archivos.

Herencia y etiquetas explícitas

Los objetos creados en un contenedor que tiene una etiqueta obligatoria heredable heredan la etiqueta obligatoria del contenedor. Sin embargo, el proceso que crea un nuevo objeto, como un archivo, puede proporcionar una etiqueta obligatoria explícita en el parámetro de atributos de seguridad para la función create, como CreateFile.

Si el proceso de creación proporciona una etiqueta explícita como parámetro para la función de creación de objetos, el nuevo objeto se asigna a la etiqueta obligatoria explícita proporcionada por el autor de la llamada y no hereda del contenedor primario. La etiqueta obligatoria explícita puede tener un nivel de integridad no superior al proceso del sujeto que crea el objeto. El nivel de integridad de la etiqueta obligatoria explícita proporcionada por el sujeto puede ser mayor que el nivel de integridad de la etiqueta obligatoria que se puede heredar del contenedor primario.

Restricción de solo herencia

Solo herencia (E/S) es una marca en una entrada de control de acceso que indica que la ACE no controla el acceso al objeto al que está asociado. Normalmente, las ACE de solo herencia se asignan a objetos de contenedor. La ACE de solo herencia no es efectiva en el propio contenedor; en su lugar, se aplica a objetos secundarios del contenedor. Hay una restricción en los sujetos con un nivel de integridad inferior al predeterminado para establecer INHERIT_ONLY etiquetas en objetos nuevos. Si la etiqueta explícita pasada para un nuevo objeto contenedor es una etiqueta INHERIT_ONLY con un nivel inferior al predeterminado, la etiqueta se considera no válida y se omite. La justificación de esta restricción es que un sujeto bajo crea un contenedor e intenta establecer una etiqueta de INHERIT_ONLY en el contenedor en un nivel bajo. Si se aceptara la etiqueta INHERIT_ONLY, el nivel de integridad efectivo para el contenedor sería el nivel predeterminado implícito de medio.

Además, los sujetos no pueden definir una etiqueta de INHERIT_ONLY con un nivel de integridad superior al nivel de integridad del sujeto. Por ejemplo, un sujeto medio no puede definir una etiqueta de INHERIT_ONLY con un nivel de integridad alto.

Herencia de etiquetas y SACL protegida

SDDL admite la definición de una SACL protegida, que podría incluir una etiqueta obligatoria explícita. La SACL protegida establece la marca SE_SACL_PROTECTED en el campo SECURITY_DESCRIPTOR_CONTROL del descriptor de seguridad. La separación lógica de LABEL_SECURITY_INFORMATION y SACL_SECURITY_INFORMATION con respecto a los derechos de acceso no está completa con respecto al comportamiento de una SACL protegida. Las etiquetas obligatorias se almacenan en sacl. Una SACL protegida implica que la etiqueta obligatoria también está protegida.

Si la marca SE_SACL_PROTECTED se establece en el SECURITY_DESCRIPTOR_CONTROL, la etiqueta obligatoria también está protegida.

  • Si no hay ninguna ace de etiqueta obligatoria en la SACL protegida, no se aplica una ACE de etiqueta obligatoria heredada del contenedor (el nuevo objeto tiene una etiqueta obligatoria predeterminada implícita).
  • Si hay una ACE de etiqueta obligatoria en la SACL protegida, los cambios realizados en la ACE de etiqueta heredable en el contenedor no afectan a este objeto.

Para obtener más información sobre SDDL, vea Apéndice A: SDDL para etiquetas obligatorias o recursos del mecanismo de integridad de Windows.

Funcionamiento de las comprobaciones de acceso con la directiva obligatoria

La función AccessCheck aplica la directiva obligatoria. AccessCheck compara el descriptor de seguridad especificado con el token de acceso especificado e indica, en el parámetro AccessStatus , si se concede o se deniega el acceso. La función AccessCheck compara primero el nivel de integridad de ClientToken con la etiqueta obligatoria en la SACL de pSecurityDescriptor para determinar qué derechos de acceso no están disponibles, en función de la directiva obligatoria. Después de la comprobación de directiva obligatoria, AccessCheck compara el acceso deseado con los derechos de acceso concedidos en la DACL.

La directiva obligatoria predeterminada impide que los procesos de integridad inferior obtengan acceso de escritura genérico a objetos de mayor integridad. Por ejemplo, de forma predeterminada, se deniega el acceso de escritura genérico a un objeto con un nivel de integridad superior. Si pSecurityDescriptor no contiene una ACE obligatoria, se supone que una ACE obligatoria implícita asigna al objeto un nivel de integridad medio. El parámetro GenericMapping determina qué derechos de acceso están asociados al acceso de escritura genérico. Si el parámetro GenericMapping es de ceros, la comprobación de integridad no concederá derechos de acceso específicos a un ClientToken de integridad inferior. Una vez que la comprobación de integridad determina los derechos de acceso genéricos que están disponibles para el autor de la llamada en función de la directiva obligatoria, la DACL del descriptor de seguridad se compara con ClientToken para determinar los derechos de acceso concedidos restantes.

Aislamiento de privilegios de interfaz de usuario (UIPI) e integridad

El aislamiento de privilegios de la interfaz de usuario (UIPI) implementa restricciones en el subsistema de Windows que impide que las aplicaciones con privilegios inferiores envíen mensajes de ventana o instalen enlaces en procesos con privilegios superiores. Las aplicaciones con privilegios superiores pueden enviar mensajes de ventana a procesos con privilegios inferiores. Las restricciones se implementan en las funciones de mensaje sendmessage y de ventana relacionada. No todos los mensajes de ventana que se envían desde un proceso con privilegios inferiores a un proceso con privilegios superiores están bloqueados. Por lo general, los mensajes de tipo "lectura", por ejemplo , WM_GETTEXT, se pueden enviar desde un privilegio inferior a una ventana con privilegios superiores. Sin embargo, se bloquean los mensajes de tipo de escritura, como WM_SETTEXT.

El nivel de privilegios de la interfaz de usuario está en el nivel de proceso y se aplica a todas las ventanas creadas por el proceso. El subsistema USER se inicializa cuando el proceso realiza la primera llamada a la interfaz del dispositivo gráfico (GDI) de Windows. Durante la inicialización del proceso, el subsistema USER llama a en el subsistema de seguridad para determinar el nivel de integridad asignado en el token de acceso de seguridad principal del proceso. Una vez que el subsistema USER establece el nivel de privilegios de la interfaz de usuario durante la inicialización del proceso, no cambia. Establecer TokenIntegrityLevel para un subproceso en un valor inferior no afecta al nivel de privilegios de la interfaz de usuario del proceso ni a las ventanas abiertas por ese proceso o subproceso.

UIPI no interfiere ni cambia el comportamiento de la mensajería de ventana entre las aplicaciones en el mismo nivel de privilegio (o integridad). UIPI impide que los procesos con privilegios inferiores accedan a procesos con privilegios más elevados bloqueando el siguiente comportamiento. Un proceso con privilegios inferiores no puede:

  • Realice una validación de identificador de ventana de un proceso que se ejecute con derechos superiores.
  • Use SendMessage o PostMessage para las ventanas de la aplicación que se ejecutan con derechos superiores. Estas API devuelven éxito, pero quitan silenciosamente el mensaje de la ventana.
  • Use enlaces de subprocesos para asociar a un proceso que se ejecuta con derechos superiores.
  • Use enlaces de diario para supervisar un proceso que se ejecuta con derechos superiores.
  • Realice la inserción de la biblioteca de vínculos dinámicos (DLL) en un proceso que se ejecuta con derechos superiores.

Con UIPI habilitado, los siguientes recursos de USUARIO compartidos todavía se comparten entre procesos en distintos niveles de privilegios.

  • Ventana de escritorio, que posee realmente la superficie de pantalla
  • Memoria compartida de solo lectura del montón de escritorio
  • Tabla atom global
  • Portapapeles

Pintar en la pantalla es otra acción que no está bloqueada por UIPI. El modelo de interfaz de dispositivo USER/graphics (GDI) no permite el control sobre las superficies de pintura. Por lo tanto, es posible que una aplicación se ejecute con menos derechos para pintar sobre la superficie de la ventana de la aplicación para una aplicación que se ejecute con derechos más altos.

UIAccess para aplicaciones de automatización de la interfaz de usuario

La automatización de la interfaz de usuario de Microsoft es el modelo de Windows Vista para admitir los requisitos de accesibilidad con mejoras en el modelo anterior, conocido como Accesibilidad activa de Microsoft (MSAA). Las aplicaciones diseñadas para admitir la experiencia del usuario accesible controlan el comportamiento de otras aplicaciones de Windows en nombre del usuario. Cuando todas las aplicaciones (el cliente y el servidor de automatización) se ejecutan como un usuario estándar, es decir, en un nivel de integridad medio, las restricciones de UIPI no interfieren con el modelo de automatización de la interfaz de usuario.

Sin embargo, puede haber ocasiones en las que un usuario administrativo ejecuta una aplicación con privilegios elevados en función de UAC en Administración modo de aprobación. El programa de automatización de la interfaz de usuario no podrá controlar la interfaz de usuario de gráficos de aplicaciones con privilegios elevados en el escritorio sin la capacidad de omitir las restricciones que IMPLEMENTA UIPI. La capacidad de omitir las restricciones de UIPI en SendMessage en los niveles de privilegios está disponible para los programas de automatización de la interfaz de usuario mediante un atributo de seguridad especial en el manifiesto de aplicación del programa, conocido como UIAccess.

A continuación se muestra un ejemplo de una entrada de manifiesto de aplicación para un programa UIAccess.

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> 
  <security> 
    <requestedPrivileges> 
    <requestedExecutionLevel 
      level="asInvoker" 
      UIAccess="true" /> 
    </requestedPrivileges> 
  </security> 
</trustInfo>

Al especificar UIAccess="true" en el atributo requestedPrivileges, la aplicación indica un requisito para omitir las restricciones de UIPI en el envío de mensajes de ventana a través de niveles de privilegios. Windows Vista implementa las siguientes comprobaciones de directiva antes de iniciar una aplicación con privilegios UIAccess.

  • La aplicación debe tener una firma digital que se pueda comprobar mediante un certificado digital que se encadene a una raíz de confianza en el almacén de certificados de entidades de certificación raíz de confianza de la máquina local.
  • La aplicación debe instalarse en un directorio de aplicación de carpeta local que solo los administradores puedan escribir, como el directorio Archivos de programa. Los directorios permitidos para las aplicaciones de automatización de la interfaz de usuario son:
    • %ProgramFiles% y sus subdirectorios.
    • %WinDir% y sus subdirectorios, excepto unos cuantos subdirectorios que están excluidos porque los usuarios estándar tienen acceso de escritura.

Los subdirectorios %WinDir% excluidos incluyen:

  • \Depuración
  • \PCHealth
  • \Registro
  • \System32\ccm
  • \System32\com
  • \System32\FxsTmp
  • \System32\Spool
  • \System32\Tasks

Windows Vista proporciona una configuración de seguridad para la directiva de equipo local y para directiva de grupo ajustar el requisito de que los programas UIAccess se deben iniciar desde ubicaciones seguras. La configuración se define en las opciones de seguridad de las directivas locales para las directivas de seguridad locales. La directiva de seguridad es la siguiente:

Control de cuentas de usuario: elevar sólo aplicaciones UIAccess instaladas en ubicaciones seguras

Este valor está habilitado de forma predeterminada. Sin embargo, un administrador puede deshabilitarlo si hay situaciones en las que las aplicaciones UIAccess (tecnología accesible) que se deben iniciar desde carpetas no están protegidas por el acceso de escritura de solo administrador.

Si la aplicación de automatización de la interfaz de usuario que solicita UIAccess cumple los requisitos de configuración de UIAccess, Windows Vista inicia la aplicación con la capacidad de omitir la mayoría de las restricciones de UIPI. Si la aplicación de automatización de la interfaz de usuario no cumple las restricciones de seguridad, la aplicación se iniciará sin derechos uiAccess y solo podrá interactuar con las aplicaciones en el mismo nivel de privilegios o inferior.

Proceso que se inicia con derechos UIAccess:

  • Tiene la capacidad de establecer la ventana de primer plano.
  • Puede controlar cualquier ventana de aplicación mediante la función SendInput.
  • Tiene entrada de lectura para todos los niveles de integridad mediante enlaces de bajo nivel, entrada sin procesar, GetKeyState, GetAsyncKeyState y GetKeyboardInput.
  • Puede establecer enlaces de diario.
  • Usa AttachThreadInput para asociar un subproceso a una cola de entrada de integridad más alta.

A las aplicaciones que se inician con derechos UIAccess para un usuario estándar se les asigna un valor de nivel de integridad ligeramente superior en el token de acceso. El nivel de integridad del token de acceso para la aplicación UIAccess para un usuario estándar es el valor de nivel de integridad medio, además de un incremento de 0x10. El nivel de integridad superior para las aplicaciones UIAccess impide que otros procesos del mismo escritorio en el nivel de integridad medio abran el objeto de proceso UIAccess.