Seguridad

Nuevas ACL mejoran la seguridad en Windows Vista

Jesper Johansson

Resumen:

• Novedades en las ACL
• Controles más estrictos en administrador
• Permisos del instalador de confianza
• Usuarios y grupos modificados

La estructura fundamental de las listas de control de acceso no ha cambiado demasiado en Windows Vista, pero existen varios cambios pequeños, aunque importantes, que debe conocer. Algunos cambios

fueron necesarios porque en Windows®XP, las ACL intervinieron en varios problemas. En primer lugar, la mayoría de los usuarios de Windows XP ejecutan como administrador. Es decir, usan una cuenta que es miembro del grupo integrado Administradores. Para usuarios domésticos, esto siempre es una certeza porque todas las cuentas que se agregan durante la instalación pasan a ser administradores. Por lo tanto todos los programas que ejecuten estos usuarios lo harán también con privilegios administrativos, otorgándoles un acceso sin restricciones al sistema operativo. Por supuesto, esto es sobre todo problemático si esos programas son de la variedad indeseable.

El segundo problema que se debía solucionar era que las ACL predeterminadas en versiones anteriores de Windows ponían a mucha gente nerviosa porque incluían entradas de ACL (ACE) para Todos, Usuarios avanzados y opciones similares. Por ejemplo, las ACL predeterminadas en la raíz del volumen de arranque (normalmente C: \) en Windows XP otorgaban acceso de lectura a Todos y permiso para crear carpetas a miembros del grupo Usuarios. Por último, en Windows XP había limitaciones en lo que se podía hacer con las ACL. Por ejemplo en Windows XP no había una manera de asignar permisos al propietario actual de un objeto. Podía asignar permisos de propietario pero al cambiar el propietario, esos permisos no se transferían. De forma similar, los propietarios siempre tuvieron derechos implícitos en un objeto, sin importar qué permisos estuvieran asignados en el mismo.

Con Windows Vista™, Microsoft se embarcó en un proyecto para resolver muchos de estos problemas y permitir otras características, tales como el Control de cuentas de usuario (UAC). Este artículo se centra en los cambios más importantes relacionados con el control de acceso en Windows Vista. El mes que viene continuaré explicando las herramientas que puede usar para administrar el control de acceso.

Usuarios y grupos nuevos y modificados

Algunos usuarios y grupos en Windows Vista son nuevos y se eliminaron algunos viejos amigos de Windows XP. Además, se modificó la manera en que algunos funcionan. Cada uno de los cambios tiene algún impacto en la manera en que administra el control de acceso.

Administrador: deshabilitado de forma predeterminada La cuenta integrada Administrador, que tiene un identificador relativo (RID) de 500, ahora está deshabilitada de forma predeterminada en la mayoría de los casos. La cuenta de administrador pretendía ser una cuenta de emergencia, usada para salvar el equipo cuando todo lo demás fallaba. No obstante, con bastante frecuencia, terminó por usarse como la cuenta administrativa estándar, con lo cual se infringen varios principios de seguridad. Uno de los más notables (la responsabilidad) significa que pierde la capacidad de realizar un seguimiento de quién realiza los cambios en el sistema. Por lo tanto, la cuenta se descartó parcialmente. En algún momento, Microsoft podría descartar la cuenta por completo, pero por ahora está deshabilitada de forma predeterminada. Si no dispone de otras cuentas locales en el grupo Administradores, aún se puede usar RID 500 en la consola de recuperación y modo seguro, pero de otra manera, no se puede, y no se debe usar.

Observe que existe una diferencia entre la cuenta integrada Administrador y otras cuentas del grupo Administradores. Normalmente, comenzamos en mayúscula "Administrador" cuando nos referimos a la cuenta con RID 500 para distinguirla de un "administrador", que son todas las otras cuentas que son miembros del grupo integrado Administradores. De igual forma, los nombres de grupo comienzan en mayúscula.

En Windows XP, la cuenta integrada Administrador tenía varios privilegios especiales que ningún otro administrador tenía. Muchos de estos privilegios se han eliminado en Windows Vista, pero existen dos excepciones notables: En primer lugar, se puede usar una cuenta deshabilitada Administrador en la consola de recuperación si no existen otros administradores locales. En segundo lugar, el Administrador no está sujeto a UAC y siempre tendrá un token administrativo completo. Lo mismo sucede con el Administrador de dominio (RID 500 en un dominio).

Permisos eliminados de Usuarios avanzados El viejo grupo Usuarios avanzados, se ha abolido para todos los fines prácticos. El grupo todavía está allí, pero se quitó la mayor parte de los permisos concedidos. No era precisamente un secreto que un usuario miembro de Usuarios avanzados era efectivamente un administrador que simplemente no se había asignado a sí mismo como administrador. Cierta vez tomé el control de un equipo al que se había aplicado todas las revisiones, y con Windows XP Service Pack 2 (SP2), en menos de 45 minutos me concedí privilegios administrativos. Esto incluyó el reconocimiento, la escritura de un pequeño programa en C ++ y el cierre y nuevo inicio de sesión para completar la toma de control, habilitado totalmente porque era miembro de Usuarios avanzados.

Muchas organizaciones han concedido permisos sofisticados al grupo Usuarios avanzados y dependen de usuarios que son miembros del mismo, de modo que en Windows Vista no era posible eliminar el grupo. Sin embargo, es probable que Microsoft elimine por completo Usuarios avanzados en una futura versión de Windows. Sería recomendable que comience a planear la migración de Usuarios avanzados.

Instalador de confianza El Instalador de confianza es en realidad un servicio, no un usuario, aunque puede ver que se le conceden permisos en todo el sistema de archivos. El sistema de protección de servicios permite que cada servicio sea tratado como una entidad completa de seguridad a la que se pueden asignar permisos como a cualquier otro usuario. Para obtener una descripción general de esta característica, consulte el número de enero de 2007 de TechNet Magazine. El libro Windows Vista Security (Grimes and Johansson, Wiley Press, 2007) explora en detalle el sistema de protección de servicios, incluido como lo aprovechan otras características, tales como el firewall e IPsec.

Los SID de servicio no se envían desde las autoridades que vimos anteriormente, como NT AUTHORITY o un dominio. El nombre completo de la cuenta virtual TrustedInstaller es NT SERVICE\TrustedInstaller y su SID es:

S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

Puede ver el SID de cualquier servicio, incluso de los que no existen, si ejecuta el comando sc showsid, tal como se muestra en la figura 1.

Figura 1** sc showsid muestra el SID de cualquier servicio, incluidos los que aún no existen **(Hacer clic en la imagen para ampliarla)

Este SID comienza con S-1-5-80. Observe que aquí la primera subautoridad es 80, lo que significa SECURITY_SERVICE_ID_BASE_RID; es decir que este SID está emitido por la subautoridad NT SERVICE para un servicio. Lo mismo sucede con todos los servicios. Las subautoridades restantes y los RID se basan en el nombre del servicio en sí mismo. Esto permite que un desarrollador conceda permisos a su servicio sin tener primero que crear e instalar el servicio porque el nombre es determinista y no variará de un equipo a otro.

En caso de que no encuentre el servicio TrustedInstaller en el administrador de servicios, su nombre para mostrar es "Instalador de módulos de Windows".

Cuentas de Ayuda y Soporte técnico eliminadas Las cuentas Support_xxxxxx y Asistente de ayuda se quitan en instalaciones limpias de Windows Vista, aunque se conservan cuando actualiza desde una versión anterior de Windows. La cuenta Support_xxxxxx se usaba para ejecutar secuencias de comandos desde el centro del soporte técnico. Algunos OEM que proporcionaban su propio contenido de ayuda pueden haber ofrecido también sus propias cuentas de soporte técnico. No está claro lo que sucederá con las cuentas OEM, pero lo más probable es que los OEM simplemente dejarán de crearlas. En realidad, ya no son necesarias. De hecho, desde una perspectiva de seguridad, no era una buena idea permitir que los usuarios ejecuten secuencias de comandos del centro de ayuda como cualquier otro usuario, de modo que sería mejor si esas cuentas desaparecen. Windows Vista tiene un nuevo mecanismo para realizar esta tarea.

La cuenta Asistente de ayuda se usaba durante la asistencia remota. Al igual que con el centro de ayuda, se realizó nuevamente la ingeniería de la característica de asistencia remota para evitar la necesidad de la cuenta Asistente de ayuda y consecuentemente ha sido eliminada.

Nuevos SID de ubicación de red Los sistemas operativos basados en Windows NT® siempre contaban con algunos SID basados en ubicación de red, tales como NETWORK e INTERACTIVE, que denotaban usuarios que iniciaban sesión desde la red e interactivamente. Hay también un SID REMOTE INTERACTIVE LOGON que se asigna a usuarios que inician sesión mediante Servicios de Terminal Server. (Observe que los usuarios de Servicios de Terminal Server tendrán en sus tokens tanto REMOTE INTERACTIVE LOGON como INTERACTIVE LOGON). En Windows Vista, se agregan dos: DIALUP e INTERNET. El fundamento exacto para agregar una cuenta que denota un inicio de sesión mediante acceso telefónico es poco claro, especialmente cuando cada vez más usuarios no se conectarán si la única red disponible es una línea telefónica, pero ahora está allí. INTERNET obviamente quiere indicar cualquier usuario que inicia sesión más allá de la red de área local. Sin embargo, NETWORK, aún designa cualquier usuario que inicia sesión en la red, incluso Internet.

OWNER RIGHTS y derechos de propietario Ahora existe un SID para OWNER RIGHTS, que se aplica a quienquiera que sea propietario de un archivo en el momento en que se obtiene acceso a éste. Se usa principalmente para restringir lo que el propietario puede hacer con el archivo. Existen dos cambios notables respecto a cómo funcionan los derechos de propietario en comparación con Windows XP. En primer lugar, si es el propietario del objeto, pero existe en él una ACE que se aplica al usuario, los derechos en la ACE sustituirán el hecho de que dicho usuario sea el propietario. Esto es un cambio importante e tendrá un impacto apreciable en ciertos aspectos de administración de sistema donde estamos acostumbrados a que el propietario tenga derechos implícitos. En segundo lugar, el SID OWNER RIGHTS se puede usar para restringir aún más lo que el propietario puede hacer con un objeto.

Supongamos que tenemos una carpeta, que es propiedad del usuario Jesper, con una ACL como la que se muestra en la figura 2. El usuario, Jesper, sólo tiene permiso de Lectura en la carpeta, aunque sea el propietario. Si intenta copiar un archivo en la misma, la copia generará un error porque Jesper no tiene permiso para escribir en la carpeta. Sin embargo, este resultado no es muy intuitivo en los mensajes de error. Si intenta copiar un archivo en una carpeta de su propiedad pero no tiene permisos de escritura para usar Explorador de Windows®, sucede lo siguiente: en primer lugar, Explorador le indica que necesita elevar los permisos para copiar el archivo y le solicita que los eleve, pero la copia del archivo genera error porque no tiene derechos para copiar en esta carpeta. Obtiene un mensaje de error que dice "Necesita permisos para realizar esta acción" y un botón "Intentar de nuevo" por cada acción (como si eso pudiera ayudar) y "Cancelar". Esto a pesar del hecho de que es el propietario.

Figura 2** Sólo Sistema local y otro usuario tienen acceso a esta carpeta **(Hacer clic en la imagen para ampliarla)

Si Jesper intenta cambiar las ACL en el archivo, se le solicitará que eleve su token para hacerlo. Dado que es el propietario del archivo, puede hacerlo. El propietario retiene derechos implícitos para leer y cambiar las ACL (READ_CONTROL y WRITE_DAC) a menos que exista una ACE para OWNER RIGHTS que especifique lo contrario.

Para entender el efecto de los SID de OWNER RIGHTS, agreguémoslos a las ACL anteriores. Ahora tenemos los permisos que se muestran en la figura 3.

Figura 3** La adición de permisos OWNER RIGHTS a la carpeta cambia los permisos de Jesper **(Hacer clic en la imagen para ampliarla)

Con estos permisos, si la cuenta de Jesper intenta copiar en la carpeta, la acción resulta correcta de inmediato porque Jesper es el propietario y tiene los derechos apropiados. Sin embargo, si Jesper intenta cambiar las ACL en el objeto, esa acción genera un error. La ACE para OWNER RIGHTS especifica que el propietario sólo tendrá el privilegio Modificar, no la capacidad de modificar la lista de control de acceso discrecional (DACL). De esta forma, OWNER RIGHTS se usa principalmente para quitar WRITE_DAC del propietario, la capacidad de modificar el descriptor de seguridad.

Si un administrador cambia el propietario del objeto, los permisos OWNER RIGHTS no se transfieren automáticamente al nuevo propietario. En este caso, la ACE de OWNER RIGHTS se deshabilita al marcarla como Sólo heredar pero sin aplicarlo en ningún contenedor ni objeto; en otras palabras, sin aplicarlo en nada. Esto se hace para asegurar que a los administradores no se les bloquee totalmente el objeto. Para que la ACE de OWNER RIGHTS tenga nuevamente efecto, el Administrador tiene que entrar y volver a habilitar la ACE de forma manual. Para ello, la debe marcar para aplicarla a esta carpeta, a las subcarpetas y a los archivos, de la forma deseada.

Existen varias situaciones interesantes en las que el SID OWNER RIGHTS puede ser útil, como por ejemplo, cuando el administrador desea que los usuarios puedan crear archivos y carpetas en un servidor de archivos, pero no desea que puedan cambiar las ACL en esas carpetas. Otra posible situación ocurre cuando en algún momento los usuarios fueron miembros de un grupo y crearon objetos pero, tal vez por razones de negocio, posteriormente fueron eliminados de este grupo. En ese momento, no podrán modificar los valores de esos objetos.

OWNER RIGHTS se usa ampliamente en el sistema de protección de servicios. Cuando un servicio crea un objeto transitorio en tiempo de ejecución, el creador del objeto es el SID principal del proceso del servicio, típicamente LocalSystem, NetworkService o LocalService, y no el SID del servicio en sí. Esto significa que cualquier otro servicio que se ejecute en el mismo contexto del proceso puede modificar el objeto, lo cual casi con toda seguridad no es deseable. Al establecer un SID de OWNER RIGHTS en dichos objetos, el sistema operativo puede impedir que otros servicios tengan acceso a ellos.

ACL predeterminadas

Las ACL predeterminadas en Windows XP eran bastante buenas en realidad. Aparte de algunos problemas secundarios, tale como permitir que los usuarios pongan los archivos en la raíz del volumen de arranque, generalmente eran razonables. Sin embargo, algunos OEM aparentemente decidieron que conocían mejor lo que constituía una seguridad razonable. La pantalla de la figura 4 muestra una imagen de las ACL en el directorio Windows de un equipo que ejecuta Windows XP Media Center Edition de un OEM de importancia. El OEM fundamentalmente deshabilitó la seguridad del sistema de archivos.

Figura 4** ACL configurada por un OEM **

Microsoft realizó algunos ajustes a las ACL en Windows Vista. En primer lugar, si está acostumbrado a Windows XP, sabe que todos los archivos del sistema operativo son propiedad del grupo Administradores y los administradores tienen control total sobre esos archivos. Como miembro de ese grupo, obtuvo acceso sin restricciones a esos archivos. No es el caso de Windows Vista.

Instalador de confianza En Windows Vista, la mayor parte de los archivos del sistema operativo son propiedad del SID TrustedInstaller y sólo ese SID tiene control total sobre éstos. Esto forma parte del trabajo de integridad del sistema que se realizó en Windows Vista y está específicamente destinado a impedir que un proceso que se ejecuta como administrador o Sistema Local reemplace automáticamente los archivos. Para eliminar un archivo de sistema operativo, necesita entonces tomar propiedad del archivo y agregar una ACE que le permita eliminarlo. Esto ofrece una capa delgada de protección contra un proceso que se ejecuta como Sistema local y tiene una etiqueta Integridad del sistema; un proceso que tiene integridad más baja no debe poder elevarse a sí mismo para cambiar la propiedad. Algunos servicios, por ejemplo, se pueden ejecutar con integridad media, aunque lo hagan como Sistema local. Tales servicios no pueden reemplazar archivos de sistema, de manera que si una vulnerabilidad de seguridad toma el control de alguno de ellos, no podrá reemplazar archivos de sistema operativo, lo que hace más difícil la instalación de un rootkit o de otro malware en el sistema. También a los administradores del sistema que se ofenden por la mera presencia de algún binario de sistema les resultará más difícil eliminar ese binario.

ACE de denegación Encontrará que muchos objetos en el sistema de archivos tienen las ACE de denegación para Todos, que han causado bastante consternación a muchos administradores. Si activa la opción "Mostrar todos los archivos ocultos", podrá ver el familiar directorio Documents and Settings. Pero si hace clic en el mismo, obtendrá el error Acceso denegado. Para entender lo que pasa en Documents and Settings, observe la lista de directorios en la figura 5.

Figura 5** Documents and Settings es un punto de unión, no un directorio **(Hacer clic en la imagen para ampliarla)

Documents and Settings de hecho, no es un directorio, ¡es un punto de unión! Recuerde que los puntos de unión son semejantes a vínculos simbólicos que simplemente redireccionan el acceso a alguna parte. En este caso, la unión va a un directorio llamado C: \Users. Microsoft modificó apreciablemente el espacio de nombres del sistema de archivos en Windows Vista, y los datos de usuario se mueven ahora a C: \Users. También se movieron otros elementos debajo del antiguo "C:\Documents and Settings\<Username>". Por ejemplo, "C:\Documents and Settings\<Username>\Application Data" se movió a C:\Users\<username>\appdata\roaming. Puede ver claramente los cambios si abre una línea de comandos y usa el comando dir/a como lo hice en la figura 5. La razón por la cual el espacio de nombres cambió tan drásticamente es para hacerlo más intuitivo para los usuarios y obtener una separación más clara entre documentos y datos. En vez de almacenar todos los archivos de datos debajo de la carpeta Mis documentos, ahora los desarrolladores pueden crear sus propias carpetas en el perfil de usuario, y el usuario las verá en esa ubicación. Los datos de programa de todos los usuarios ahora entran en una carpeta oculta denominada %systemroot%\ProgramData en vez de estar debajo de Documents and Settings\All Users\Application Data.

Microsoft no eliminó el espacio de nombres "C:\Documents and Settings" porque los antiguos programas pueden estar codificados para usar ese nombre en lugar de las variables de entorno preferidas, tal como %USERPROFILE%. Estas aplicaciones se interrumpirían si desaparece "C:\Documents and Settings". En lugar de eso, ahora están representados como puntos de unión o symlinks, para compatibilidad con versiones anteriores. Es posible que las aplicaciones que codifican esas rutas de acceso aún se interrumpan, en función de cómo tengan acceso a los datos en las mismas, pero esas mismas aplicaciones ya se interrumpen en versiones de Windows en idiomas distintos del inglés. En realidad esta es la clave. Cuando una actualización de Windows, como Windows XP SP2 o Windows Vista, interrumpe programas de terceros, casi siempre se debe a que los desarrolladores de esos programas hicieron suposiciones no válidas o usaron Windows de una manera inapropiada.

Si intenta abrir un archivo, por ejemplo si escribe “C:\Documents and Settings\<Username>\My Documents\foo.txt", funcionará, siempre y cuando exista un archivo en ese lugar llamado foo.txt. Sin embargo, si trata de examinar en "C:\Documents and Settings\<Username>\My Documents", obtendrá el mensaje de error "Acceso denegado". Para entender lo que sucede, mire las ACL en la figura 6.

Figura 6** Existe una ACE de denegación en Documents and Settings **(Hacer clic en la imagen para ampliarla)

Observe la primera ACE de la lista. Es una ACE de denegación para enumerar los contenidos de carpeta para Todos. Los programas pueden atravesar los puntos de unión y abrir documentos con rutas de acceso absolutas porque Todos tiene el privilegio Omitir comprobación de recorrido (también conocido como SeChangeNotifyPrivilege). Los intentos que realicen un usuario o proceso para enumerar los directorios que representan generarán errores a causa de la ACE de denegación. Debido a esto, no puede ver en realidad lo que se encuentra en el interior de C:\Documents and Settings, ni puede eliminar el "directorio". La idea fundamental de poner esa ACE de denegación es impedir que los usuarios eliminen la unión e interrumpan las antiguas aplicaciones. También sirve recordar a los desarrolladores que no codifiquen las aplicaciones usando el antiguo espacio de nombres y que, en su lugar, comiencen a usar variables de entorno o cadenas de registro para aislar la aplicación de cualquier cambio futuro y diferencias de idioma.

Observe que todos estos puntos de unión de forma predeterminada permanecen ocultos, de modo que la inmensa mayoría de usuarios nunca los verá. Para impedir que quienes los ven los eliminen, Microsoft puso una ACE de denegación en "Mostrar lista de carpetas".

Omitir comprobación de recorrido La razón por la cual los usuarios pueden tener acceso a archivos en los que tienen derechos en el interior de carpetas (o puntos de unión) en los que no tienen derechos es que todos tienen el privilegio Omitir comprobación de recorrido. Omitir comprobación de recorrido, o SeChangeNotifyPrivilege, es realmente el privilegio más básico en Windows y se concede a un proceso al que se quitaron todos los demás privilegios a menos que el proceso solicite específicamente que se quite también ese privilegio. Esto es lo que sucede cuando inicia un proceso que usa la línea runas /trustlevel:0x10000 <en Windows Vista. El programa especificado en <command> se ejecutará con un token restringido y todos los privilegios con excepción de SeChangeNotifyPrivilege se quitarán del token del proceso.

Como aspecto interesante, trustlevel 0x20000 le proporciona un token que posee el conjunto normal de SID pero para el que se han quitado los privilegios. 0x40000 le proporciona un token completamente normal.

Permisos predeterminados

Los permisos predeterminados en el sistema de archivos en Windows Vista han cambiado un poco con respecto a Windows XP. Si observa las ACL en %systemdrive% (normalmente la unidad C:, el volumen de arranque), en Windows XP o Windows Server® 2003, verá lo siguiente (o algo muy semejante en versiones anteriores a Windows XP):

D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU) 

Esta es la misma ACL en el mismo directorio de Windows Vista:

D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU) 

Hay varias diferencias que cabe destacar. En primer lugar, ahora existen dos ACE para BA (BUILTIN\Administrators) en lugar de sólo una. Sin embargo, el resultado final es el mismo. En Windows Vista, una ACE no se hereda y concede acceso completo a la raíz, y una ACE es una ACE de IO (Sólo heredar), heredada por contenedores y objetos, y concede GA (Todo genérico o control total). Lo mismo se aplica en el reemplazo de la única ACE para SY (Sistema local) por dos en Windows Vista. En Windows XP, la única ACE concedía control total y la heredaban los objetos y contenedores. Nuevamente, no existen cambios. La razón principal por la cual se modificaron las ACL fue clarificar y dividir los privilegios para que las ACL sean más fáciles de administrar e incluso potencialmente de restaurar.

Lo más interesante es que desaparece la ACE para CO (Creador/Propietario). Eso significa que si un usuario crea un objeto en la raíz del sistema de archivos, ya no existen permisos especiales acumulados para el creador.

También puede observar que se quitó la ACE para WD (Todos). Muchas personas interesadas en seguridad, que no entendían quizá completamente las consecuencias de sus acciones, estaban indebidamente preocupadas por esta ACE. Durante años, Microsoft intentó en vano explicar que Todos era funcionalmente idéntico al Usuarios integrados, pero parece que finalmente renunciaron y eliminaron por completo esa ACE. Debido a que existe una ACE idéntica para BU (BUILTIN\Users) heredada también tanto por contenedores como por objetos, el resultado final es que nada ha cambiado.

Además, dos de las ACE para BU (Usuarios integrados) han sido reemplazadas con las ACE para AU (Usuarios autenticados). La razón es que la cuenta Invitado es miembro de Usuarios integrados (en virtud del hecho de que INTERACTIVE es miembro de Usuarios integrados), pero Invitado no es miembro de Usuarios autenticados. Para permitir que la cuenta Invitado lea y ejecute archivos, la ACE 0x1200a9 (Lectura y ejecución efectivas) permanece concedida a BU. Sin embargo, las ACE que conceden permisos para crear archivos y carpetas se conceden en cambio a Usuarios autenticados. Este es un cambio respecto de Windows XP. En Windows XP, un Invitado podía crear archivos en la raíz. En Windows Vista, un Invitado no puede crear dichos archivos. Aún así, tenga presente que todo esto es discutible a menos que se habilite la cuenta Invitado y los invitados puedan de algún modo alcanzar la raíz del volumen de arranque. De forma predeterminada, la cuenta Invitado está deshabilitada.

Como he dejado lo mejor para el final, hay un par de ACE muy interesantes y aparentemente fastidiosas en las dos listas anteriores. En Windows XP, dispone de una ACE heredada por contenedores, al especificar 0x100004 para Usuarios integrados. Esa ACE concede a los Usuarios el derecho de crear subcarpetas y subcarpetas dentro de éstas, etc., debido a que es heredada por los contenedores. También existe una ACE de sólo heredar, heredada por subcarpetas para 0x100002. Esa ACE concede a los usuarios el derecho de crear archivos y subcarpetas en carpetas que crean bajo la raíz. Es decir, estas dos ACE permiten a los usuarios, incluidos los Invitados, crear archivos y carpetas bajo la raíz, tal como mencioné antes.

En Windows Vista, las ACE correspondientes son ACE de sólo heredar, heredadas tanto por contenedores como por archivos, que conceden GR (lectura genérica), GX (ejecución genérica) y GW (escritura genérica) junto con un SD (descriptor de seguridad de lectura) y una ACE que se aplica sólo a la raíz en sí que concede el privilegio LC. LC es realmente un término abreviado que pertenece a las ACE en Active Directory®. En Active Directory significa que un usuario puede listar objetos secundarios. Sin embargo, el valor hexadecimal de LC es 0x4. Para un directorio, 0x4 significa FILE_ ADD_SUBDIRECTORY, funcionalmente equivalente a 0x100004, porque ya contamos con 0x100000 (la capacidad de usar el objeto para la sincronización) de la ACE 0x1200a9. Es decir, ofrece exactamente el mismo efecto que en Windows XP; los usuarios pueden crear subdirectorios bajo la raíz.

¿De dónde provienen los valores hexadecimales? ¿Y, qué significan los valores hexadecimales en primer lugar? Como ya se habrá dado cuenta, el control de acceso está lleno de números hexadecimales (base16), como por ejemplo, 0x1200a9. En realidad, son representaciones de máscara de bits en una máscara de acceso y que se establecen en "activado", lo que significa que se usan en una ACE específica. Al usar una herramienta, tal como icacls, sc o secedit para listar una ACL, las máscaras de bits se representan con cadenas de texto mucho más descriptivas si existe una coincidencia 1:1.

Por lo tanto, para determinar lo que significa LC todo lo que tiene que hacer es ir al sitio web de MSDN®, buscar la cadena LC y mirar en la columna del valor de derecho de acceso para encontrar ADS_RIGHT_ACTRL_DS_LIST. Si a continuación abre el archivo de encabezado Iads.h y busca esa cadena, encontrará que corresponde a 0x4. Para cadenas que no pertenecen a Active Directory (las que no comienzan con "ADS_RIGHT"), generalmente encontrará el valor hexadecimal en AccCtrl.h. Una vez que tiene el valor hexadecimal, es un trabajo fácil buscar en la máscara de acceso en WinNt.h o AccCtrl.h para ver lo que significa en realidad.

Si necesita ayuda, es recomendable obtener una copia del libro Protect Your Windows Network (por Jesper Johansson y Steve Riley, Addison-Wesley, 2005). El capítulo 17 trata en profundidad cómo analizar cadenas y ACE del Lenguaje de definición de descriptores de seguridad (SDDL).

Los permisos concedidos a esos subdirectorios se controlan únicamente mediante las ACE (A;OICIIO;SDGXGWGR;AU) en Windows Vista, lo que constituye la mayor diferencia entre Windows Vista y Windows XP. En lugar de conceder control total al creador de los subdirectorios, como en Windows XP, Windows Vista concede a los usuarios autenticados privilegios para modificar.

El resultado final de estas nuevas ACL es que el creador de un objeto ya no tiene ningún derecho especial y que todo resulta más claro. Quizá el mayor cambio es que Usuarios autenticados tiene privilegios para Modificar incluso en subcarpetas creadas por administradores, lo cual es muy diferente de Windows XP. En Windows XP, Usuarios y Usuarios autenticados no tienen derechos en los objetos creados por los administradores bajo la raíz. Sin embargo, en su conjunto, aunque estas ACE pueden parecer molestas, el resultado final no es muy diferente al de Windows XP.

En resumen, en Windows Vista todos, incluido el usuario Invitado, pueden leer y ejecutar archivos en la raíz. Sólo los usuarios autenticados pueden crear nuevos archivos y carpetas, y cuando lo hacen, pueden modificar permisos en esos archivos y carpetas. Es decir, los permisos son ligeramente más estrictos en Windows Vista que en Windows XP, aunque cabe destacar que la cuenta Invitado está deshabilitada de forma predeterminada.

Cambios en tokens

Cuando un usuario que es miembro del grupo Administradores inicia sesión en Windows XP, su token contiene el SID del grupo Administradores y puede hacer todo lo que el grupo Administradores puede hacer. En Windows Vista, por otro lado, esto ya no es así debido al Control de cuentas de usuario. El SID de Administradores todavía está presente en el token, pero se establece en Sólo denegar, tal como se muestra en la captura de pantalla de Process Explorer de la figura 7.

Figura 7** En UAC, el SID de Administradores sólo se usa para denegar el acceso a menos que lo eleve **(Hacer clic en la imagen para ampliarla)

Al realizar el control de acceso, dicha entrada en el token se usa sólo para denegar el acceso; en otras palabras, para hacer coincidir las ACE de denegación. Cualquier ACE para permitir de ese SID será omitida. Esto significa que el usuario no es verdaderamente un administrador todo el tiempo, aún si inicia sesión en el sistema como tal.

Niveles de integridad

Ahora Windows admite el etiquetado de procesos y objetos con niveles de integridad. Estos niveles de integridad también se representan como ACE, pero no en la DACL. En lugar de eso, forman parte de la lista de control de acceso de sistema (SACL), con algunos marcadores especiales. Por ejemplo, el marcador NW se usa para indicar el bloqueo de un proceso a un nivel de integridad más bajo para escribir en un objeto a un nivel de integridad más alto (SDDL_NO_WRITE_UP). Mark Russinovich desarrolla extensamente este tema en su artículo "Dentro del Control de cuentas de usuario de Windows Vista" en este mismo número de TechNet Magazine.

Conclusión

Aunque no existe una modificación única y trascendental para el control de acceso en Windows Vista, como sucedió con Windows 2000, hay una cantidad de pequeños cambios. Cuando los observa por separado no parecen demasiado, pero tomados en conjunto significan en realidad que debe volver a pensar mucho en lo que hace cuando administra su sistema. Además, estos cambios son compatibles con una serie de diferentes iniciativas, de las cuales las más notables son UAC y el sistema de protección de servicios. Algunos administradores se pueden frustrar bastante al comenzar a usar Windows Vista por primera vez. Ya he escuchado comentarios sobre "sistemas operativos tiranos" que restringen la capacidad de eliminar partes del sistema operativo que, por una razón u otra, parecen ofensivas. Sin embargo, hay razones sólidas en todos los cambios y, lo más probable es que si dedica un poco de tiempo para analizar lo realizado, entenderá los motivos.

Jesper Johansson es arquitecto de seguridad en una gran empresa de comercio electrónico, responsable de la estrategia de seguridad de aplicaciones en la gama de las propiedades y los servicios. Ha trabajado durante 20 años en seguridad y es autor de numerosos artículos y dos libros sobre seguridad. Cuando no trabaja en seguridad de la información, se dedica a enseñar buceo.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.