Desde que salió a la luz Windows Vista, y ahora con las versiones preliminares de Windows 7, me he dado cuenta de que el número de problemas cuya solución implica el registro de una DLL (mediante el comando regsvr32 nombreDLL) ha descendido notablemente en estos dos últimos sistemas operativos. Una de las causas de esto, para mí, es la inclusión de Windows Resource Protection (WRP), mecanismo que garantiza la integridad de los componentes vitales del sistema operativo y que supone una tremenda mejora con respecto a Windows File Protection (WFP), sistema de protección de archivos de sistema presente en Windows 2000 y XP.
Windows File Protection (WFP)
Windows 2000 y XP incorporaron una característica denominada WFP (Windows File Protection), encargada de proteger los archivos más importantes del sistema operativo para evitar que sean modificados o eliminados.
Su funcionamiento se basa en uno o varios hilos de tipo centinela residentes en el proceso Winlogon e implementados en la DLL Sfc_os.dll. Es decir, estos hilos están al tanto de cualquier tipo de modificación que se realice sobre directorios del sistema (típicamente \System32 y \System32\drivers). Si hubiera cambiado alguna DLL de estos directorios, se registra dicho suceso en una cola destinada a tal efecto. En ese momento se señaliza un evento que despierta a otro hilo encargado de realizar la verificación del correspondiente archivo y su recuperación desde la cache (carpeta oculta \WINDOWS\System32\dllcache). Si no estuviera en cache, se mostrará una interfaz al usuario informándole de tal situación e invitándole a introducir el CD de Windows 2000/XP para intentar recuperar la versión original del archivo.
Windows Resource Protection (WRP)
La llegada de Windows Vista supuso que la estructura interna del sistema operativo cambiara radicalmente. Ahora el sistema operativo está formado por componentes, claves de Registro, manifiestos XML y ficheros binarios, entre otras cosas, por lo que la aproximación empleada en versiones anteriores de Windows ya no podía seguir siendo válida. Este aspecto puede ser interpretado como una ventaja, pues si se desarrolla un sistema de protección para cada uno de los componentes del sistema operativo, ya no solo estaremos protegiendo ejecutables y DLL, como en Windows 2000/XP, sino que estaremos protegiendo también claves de Registro y otro tipo de recursos que son igualmente vitales para el correcto funcionamiento del equipo. Este sistema de protección recibió el nombre de Windows Resource Protection (WRP).
Cada uno de los componentes que conforman el sistema operativo Windows Vista/Windows 7 contiene un fichero denominado manifiesto. Un manifiesto es un fichero de tipo XML que contiene información específica sobre el componente, es decir, archivos que lo componen, archivos de los que depende, claves de Registro, privilegios con los que se ejecutará por defecto, idioma, etc. Uno de estos posibles parámetros (etiquetas XML) es la protección del recurso en cuestión, etiqueta <systemProtection></systemProtection>. Existen distintos valores posibles para el parámetro behavior (comportamiento) de esa etiqueta:
- readOnlyIgnoreWrites: El recurso solo puede ser modificado por el sistema operativo, durante una instalación (servicio TrustedInstaller). Cualquier intento de escritura por parte de una aplicación será descartado; es decir, se le informará de que la escritura se realizó con éxito pero el fichero no se verá modificado.
- readOnlyFailWrites: El recurso solo puede ser modificado por el sistema operativo, durante una instalación (servicio TrustedInstaller). Cualquier intento de escritura por parte de una aplicación tendrá como consecuencia que reciba un error.
- OSOnlyIgnoreWrites: Similar a readOnlyIgnoreWrites, pero las modificaciones las puede hacer cualquier componente del sistema operativo.
- OSOnlyFailWrites: Similar a readOnlyFailWrites, pero las modificaciones las puede hacer cualquier componente del sistema operativo.
- applicationVirtualized: Cualquier cambio que se haga sobre el recurso supondrá que el sistema operativo cree una copia privada a la aplicación que lo ha modificado. El recurso global no se ve modificado.
- userVirtualized: Similar a applicationVirtualized pero la copia privada es por usuario, no por aplicación.
En el mismo fichero de manifiesto se indica también qué descriptor de seguridad usar para dicho componente. Por ejemplo, la carpeta Winsxs de Windows Vista tiene este descriptor de seguridad:
O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
G:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
D:PAI
- (A;OICI;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)
- (A;OICI;0x1200a9;;;BA)
- (A;OICI;0x1200a9;;;SY)
- (A;OICI;0x1200a9;;;BU)"
Donde S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 es el SID de TrustedInstaller, un servicio encargado de instalar actualizaciones y componentes en Windows Vista y Windows 7.
Vamos a explicar un poco el descriptor de seguridad: Las dos primeras líneas indican que el propietario (O, de owner) como el grupo (G, de group) es TrustedInstaller. La línea D:PAI quiere decir que el DACL es protegido (es decir, que no hereda listas de control de acceso o ACL) y además se hereda automáticamente. A continuación se indica que TrustedInstaller tiene acceso total al recurso (FA, de full access); el grupo de administradores, sistema y usuario (BA, SY y BU, respectivamente) tienen acceso genérico de lectura/escritura. Así pues, ni siquiera un administrador podrá modificar el contenido del directorio Winsxs. Tan solo TrustedInstaller, con motivo de la instalación/desinstalación de actualizaciones, Service Packs o componentes opcionales de Windows podrá modificar ese directorio.
Si quiere saber más sobre ACL y DACL le recomiendo el libro Windows Internals, escrito por Mark Russinovich y David Solomon, ya sea en su cuarta o su quinta edición.
Veámoslo con un ejemplo
Abriendo el fichero de manifiesto del componente Bloc de notas de Windows Vista podemos observar entre otras cosas lo siguiente:
<dependentAssembly>
<assemblyIdentity name="Microsoft-Windows-Kernel32" version="6.0.6001.18000" processorArchitecture="x86" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" />
</dependentAssembly>
Aquí se hace referencia a que Bloc de notas depende del componente Microsoft-Windows-Kernel32 (que contiene entre otras cosas la DLL Kernel32.dll) para funcionar correctamente.
<systemProtection xmlns="urn:schemas-microsoft-com:asm.v3" behavior="readOnlyFailWrites" perUserVirtualization="Disabled" />
Aquí se hace referencia a que cualquier intento de escritura sobre el componente Bloc de notas dará como resultado un error y no se llevará a cabo la modificación. La virtualización está desactivada, por tratarse de un componente de Windows.
<shortCut arguments="" destinationPath="$(runtime.documentsSettings)\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessories" destinationName="Notepad.lnk" targetPath="$(runtime.system32)\notepad.exe" iconPath="$(runtime.system32)\notepad.exe,0" windowStyle="normal" workingDirectory="%HOMEDRIVE%%HOMEPATH%" description="@%SystemRoot%\system32\Shell32.dll,-22563" displayResource="$(runtime.system32)\shell32.dll,22051" />
Aquí se hace referencia a la configuración del acceso directo al bloc de notas que hay en el menú Inicio.
<registryKey keyName="HKEY_CLASSES_ROOT\Applications\notepad.exe\shell\open\command" owner="false">
<registryValue name="" valueType="REG_EXPAND_SZ" value="%SystemRoot%\system32\NOTEPAD.EXE %1" operationHint="replace" owner="true" />
Aquí se hace referencia a una de las claves de Registro gobernadas por Bloc de notas, la correspondiente a las asociaciones de ficheros.
Como puede observar, la integridad del sistema operativo fue uno de los objetivos principales para Microsoft mientras diseñaba Windows Vista. La protección de todos y cada uno de los recursos vitales del sistema operativo mediante Windows Resource Protection (WRP) hacen que Windows Vista y Windows 7 sean sistemas mucho más estables y robustos que sus predecesores.
Si se hiciera un listado con las consultas más frecuentes en los foros de Windows, seguro que esta ocuparía una posición bastante destacada: ¿Por qué no puedo cambiar el atributo de solo lectura a una carpeta de mi sistema?
Pese a que Microsoft dispone de un artículo al respecto (KB326549), considero que mucha gente aún tiene dudas sobre este tema y por eso me he decidido a escribir este artículo.
Si un usuario hace clic con el botón derecho sobre una carpeta de su sistema y selecciona Propiedades, le aparecerá un cuadro de diálogo similar al siguiente (en un sistema XP):
Como puede observar en la imagen, la casilla Sólo lectura tiene un aspecto particular: No está marcada, pues no aparece la típica marca de verificación en el cuadrado blanco, ni tampoco está desmarcada, pues el color del cuadrado no es blanco sino verdoso. ¿Qué significa esto? Esa casilla es una casilla de tipo triestado; es decir, hay tres posibles estados para esa casilla: Marcada, desmarcada e indeterminada, que es el caso que nos ocupa. Si hace clic varias veces sobre la casilla Sólo lectura podrá ver que va cambiando el estado de la misma. Sin embargo, pese a dejar la casilla en estado marcado y pulsar Aceptar, al volver a abrir las propiedades de la carpeta la casilla vuelve al estado indeterminado.
¿Cuál es la causa de esto?
La causa de este comportamiento es que el atributo de sólo lectura no se puede cambiar, para carpetas, desde la interfaz de Windows. Microsoft tomó esta decisión porque el atributo de sólo lectura aplicado a carpetas tiene una semántica que nada tiene que ver con la del atributo de sólo lectura aplicado a ficheros. El atributo de sólo lectura aplicado a carpetas únicamente quiere decir que la carpeta es una carpeta personalizada (con un icono distintivo, con un fondo, etc.).
Debe quedar claro que el atributo de sólo lectura aplicado a una carpeta no quiere decir que la carpeta no se pueda eliminar o cosas por el estilo.
¿Para qué está la casilla Sólo lectura en las propiedades de una carpeta?
Está presente porque puede aplicarse a los ficheros que contenga esa carpeta. Si desmarca la casilla Sólo lectura en las propiedades de una carpeta y pulsa Aceptar, lo que ocurre es que se quita el atributo de sólo lectura a todos los ficheros que contenga esa carpeta, si es que contiene alguno. De igual forma, si establece el estado de la casilla como marcado (con una marca de verificación en el cuadrado blanco) y pulsa Aceptar, todos los ficheros de esa carpeta pasarán a tomar el atributo de sólo lectura.
Entonces, ¿cómo cambiar el atributo de sólo lectura a una carpeta?
Como ha podido ver, Explorador de Windows no permite que el usuario cambie el atributo de sólo lectura a una carpeta. Esto se debe a que Microsoft no quiere que los usuarios "jueguen" con este atributo, lo que podría suponer que se perdieran las personalizaciones de algunas carpetas del equipo, incluidas algunas carpetas de sistema importantes para Windows. Así pues, si un usuario quiere "jugar" con el atributo de sólo lectura aplicado a una carpeta, debe hacerlo desde la línea de comandos usando el comando Attrib.exe de un modo similar al siguiente:
attrib +r <Ruta_carpeta>
Esto aplicaría el atributo de sólo lectura a la carpeta indicada por <Ruta_carpeta>
Similarmente, el comando
attrib -r <Ruta_carpeta>
desactivaría este atributo.
Espero que este artículo sirva para aclarar de manera definitiva en qué consiste exactamente el atributo de sólo lectura cuando se aplica a una carpeta, por qué Explorador de Windows siempre muestra la casilla correspondiente como indeterminada, y qué ocurre cuando el usuario deja esa casilla en estado marcado o en estado desmarcado y pulsa sobre Aceptar.