Detectando la virtualización del registro

Question

Tengo un conjunto de aplicaciones C# (v2) y estoy luchando con la virtualización del registro en Win7 (y en menor medida en Vista).

Tengo un área de configuración de registro compartida a la que mis aplicaciones deben acceder en HKLM \ Software \ Company ... Antes de Vista, todo lo que se escribía y se leía desde esa ubicación era necesario.

El código detectó correctamente las fallas al escribir en esa clave de registro y se caería de manera adecuada (escribiendo a HKCU y notificando al usuario que la configuración que habían aplicado solo afectaría al usuario actual).

En Vista, la virtualización de registro rompió todo esto porque la verificación de acceso que estábamos utilizando para la escritura HKLM "tendría éxito" silenciosamente y se virtualizaría a HKCR \ VirtualStore \ Machine ... en su lugar. En este caso, el usuario pensaría que ha guardado la configuración de toda la máquina, pero en su lugar solo ha escrito en la tienda virtual.

Lamentablemente, incluso al intentar enumerar los permisos en la clave de registro HKLM, se obtienen resultados que indican explícitamente que el usuario tiene acceso, lo hagan o no.

Cuando agregamos el soporte de Vista, la solución que utilizamos fue realizar una prueba de escritura en HKLM ... y luego verificar en HKCR \ VirtualStore \ Machine ... por el mismo valor y observar que la virtualización había ocurrido si el valor fue encontrado.

Win7 parece haber roto esto (de nuevo) porque las consultas contra la ubicación virtual explícita (HKCR) ahora muestran resultados combinados de la ubicación HKLM incluso si la escritura no se virtualizó.

¿Alguien tiene alguna sugerencia para solucionar este problema?

Restricciones: - Necesito una solución que funcione sin requerir elevación (cuando no tengo permisos de nivel de administrador, recurriré a una configuración por usuario en HKCU, pero debo ser capaz de detectar este caso de manera confiable) .

• Se necesita trabajar con una aplicación v2 C# (Una de las opciones que he visto en código C++ es integrar un manifiesto que desactiva la virtualización para el .exe pero no han sido capaces de hacer eso en C# V2 ver disable folder virtualization in windows).

• Tiene que funcionar sin un "instalador" (esto imposibilita la capacidad de deshabilitar la virtualización en la clave de registro que necesitamos al comando REG FLAGS ...).

Answer 1

Puede activar/desactivar la virtualización en una base por clave, según this, pero le dice a utilizar una herramienta de línea de comandos. Pero debe haber una manera de hacerlo programáticamente.

Podría ser más fácil simplemente desactivar la virtualización en su aplicación configurando requiredExecutionLevel en su manifiesto. Puede probar highestAvailable, pero eso podría significar que su aplicación siempre se ejecuta como administrador. Parece implicar solo establecerlo ya que Invoker desactivará la virtualización. Ver also.

Answer 2

Tenga en cuenta que HKCR es una tienda virtualizada en sí, una combinación de HKLM\Software\Classes y HKCU\Software\Classes.

El mejor enfoque sería no permitir que la virtualización del registro tenga lugar.En primer lugar, compruebe que el usuario esté elevado en tiempo de ejecución y luego puede notificar al usuario que los cambios solo se aplicarán al usuario actual incluso antes de que comiencen a realizar cambios.

Al detectar si usted es un administrador elevado en primer lugar, simplemente puede evitar escribir en HKLM cuando se va a virtualizar.

Ejemplo:

private bool IsAdministrator 
{ 
    get 
    { 
     WindowsIdentity wi = WindowsIdentity.GetCurrent(); 
     WindowsPrincipal wp = new WindowsPrincipal(wi); 

     return wp.IsInRole(WindowsBuiltInRole.Administrator); 
    } 
} 

Nota: No código en C#, se levanta ejemplo de la pregunta How can I detect if my process is running UAC-elevated or not?

Answer 3

Ésta es una pregunta excelente puesto, 1 (¿Por qué es la comunidad wiki , merece puntos!)

En general, hay un conjunto de reglas (que [como se ha topado] variarán a lo largo del tiempo) que controlan si la virtualización UAC [y por lo tanto implícitamente el Registro] está en juego.

Algunas partes sobresalientes de la Registry Virtualization rulesets documentation in MSDN son:

1. [como dice jeffamaphone] si el manifiesto tiene un conjunto requestedPrivileges/requestedExecutionLevel, es desactivado. Parece que no has descartado agregar un manifiesto, así que ¿podrías indicar por qué no funcionará para ti? (Usted dice "No he podido hacer eso en C# V2" - hay una opción Agregar elemento para agregar un archivo de manifiesto de aplicación, y está disponible en VS2005)
2. si el exe está ejecutando 64 bit, está desactivado por defecto
3. si no es un proceso interactivo (como un servicio, o alojado en IIS, etc.), que está fuera

Si no está en condiciones de influir en cualquiera de los anteriores, que es el ideal, y por lo tanto desea detectar si la virtualización de UAC se aplica en el contexto actual, use this answer to a what might at first not appeat to be a related question. (Obviamente, aún tendría que decidir si se aplica a la tecla específica en la que está operando, que es un objetivo móvil que obviamente no desea implementar código que necesita rastrear cambios si puede evitarse en absoluto, pero en la mayoría de los casos debería ser relativamente claro.)

Answer 4

Tuve un problema similar y la presentación de un manifiesto lo resolvió.

Estaba confiando en la seguridad del registro para evitar que la aplicación (Win32) creara claves en el HKLM/Software/Wow6432Node cuando se ejecuta como usuario estándar, y me sorprendió ver que estaba teniendo éxito independientemente, pero no había ninguna clave presente y fue creado en su lugar bajo esta nueva área de VirtualStore.

La virtualización del registro se desactiva cuando se encuentra que el manifiesto PE contiene información relacionada con la seguridad. Para no requerir la elevación de privilegios mi manifiesto contiene el nodo siguiente:

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

Para el ejecutable para que sea compatible con Vista y XP, al parecer, cada nodo en la sección TrustInfo debe contener los nombres:

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

Una vez que el manifiesto se incrustó correctamente en mi .exe (me costó un par de intentos al modificar las propiedades apropiadas del proyecto), el programa finalmente estaba fallando como estaba esperando.

Para el código administrado, el manifiesto se puede incluir como un paso posterior a la compilación ejecutando la herramienta mt.exe. Por ejemplo, como se informa en la MSDN article

mt.exe –manifest YourFile.manifest –outputresource:YourApp.exe;#1 

Yo prefiero usar el enfoque manifiesta en lugar de modificar las banderas de los nodos de registro utilizando reg.exe como se explica en this article ya que esto hace que el comportamiento coherente en todas las máquinas.

Esperamos que ayuda (incluso si, después de haber leído la fecha de la publicación original, estoy bastante seguro de que el problema ha sido resuelto hace mucho tiempo !!)

Alberto