{"id":106,"date":"2007-06-14T12:39:22","date_gmt":"2007-06-14T15:39:22","guid":{"rendered":"http:\/\/www.radians.com.ar\/blog\/?p=106"},"modified":"2008-07-26T13:28:22","modified_gmt":"2008-07-26T16:28:22","slug":"estudio-del-control-de-cuenta-de-usuario-uac-de-windows-vista","status":"publish","type":"post","link":"https:\/\/www.radians.com.ar\/blog\/?p=106","title":{"rendered":"Estudio del control de cuenta de usuario (UAC) de Windows Vista"},"content":{"rendered":"

Ya he hablado recientemente en una nota sobre esta nueva funcionalidad en Windows Vista, y algunas de las complicaciones que a mi particularmente me trajo y como desactivarlo, ahora Microsoft en la revista TechNet<\/strong> se publico una nota muy muy completa al respecto que me gustaria compartirla con ustedes.<\/p>\n

Saludos, Roberto Di’Lello.<\/p>\n

\n

El control de cuentas de usuario (UAC) es a menudo una caracter\u00edstica mal comprendida en Windows Vista. En mi serie de TechNet Magazine<\/em> de tres partes acerca de los cambios del n\u00facleo de Windows Vista, disponible en l\u00ednea en la direcci\u00f3n technetmagazine.com<\/strong><\/a>, no habl\u00e9 de UAC porque sent\u00eda que se merec\u00eda su propio art\u00edculo.En este art\u00edculo hablo de los problemas que UAC resuelve y describo la arquitectura y la implementaci\u00f3n de las tecnolog\u00edas de sus componentes. Entre estas tecnolog\u00edas se incluyen la refactorizaci\u00f3n de las operaciones que anteriormente requer\u00edan derechos administrativos, la virtualizaci\u00f3n ligera para ayudar a los programas a ejecutarse correctamente sin derechos administrativos, la capacidad de los programas de solicitar expl\u00edcitamente derechos administrativos y el aislamiento de los procesos administrativos de los procesos no administrativos que se ejecutan en el mismo escritorio de usuario.<\/p>\n

Objetivo de UAC<\/strong><\/p>\n

UAC sirve para permitir a los usuarios ejecutar operaciones con derechos de usuario est\u00e1ndar, en contraposici\u00f3n con los derechos administrativos. Los derechos administrativos ofrecen a los usuarios la capacidad de leer y de modificar cualquier parte del sistema operativo, como por ejemplo, el c\u00f3digo y los datos de otros usuarios, e incluso el propio Windows\u00ae<\/sup>. Sin derechos administrativos, los usuarios no pueden modificar de manera accidental (o deliberadamente) la configuraci\u00f3n del sistema, el malware no puede modificar la configuraci\u00f3n de seguridad del sistema ni deshabilitar software antivirus y los usuarios no pueden poner en peligro la informaci\u00f3n confidencial de otros usuarios en equipos compartidos. La ejecuci\u00f3n con derechos de usuario est\u00e1ndar puede, por tanto, reducir las llamadas al departamento de soporte t\u00e9cnico urgentes en entornos corporativos, mitigar la repercusi\u00f3n del malware, mantener la ejecuci\u00f3n sin problemas de los equipos dom\u00e9sticos y proteger los datos confidenciales de los equipos compartidos.<\/p>\n

UAC tuvo que tratar varios problemas para que fuera pr\u00e1ctica la ejecuci\u00f3n con una cuenta de usuario est\u00e1ndar. En primer lugar, antes de Windows Vista\u2122, el modelo del uso de Windows ha sido uno en que se supon\u00edan derechos administrativos. Los programadores de software supon\u00edan que sus programas podr\u00edan tener acceso y modificar cualquier archivo, clave de Registro o configuraci\u00f3n del sistema operativo. Incluso cuando Windows NT\u00ae<\/sup> incorpor\u00f3 seguridad y diferenci\u00f3 entre accesos concedidos a cuentas de usuario est\u00e1ndar y administrativas, se guiaba a los usuarios a trav\u00e9s de un proceso de configuraci\u00f3n que les animaba a usar la cuenta de administrador integrada o una que fuera miembro del grupo Administradores.<\/p>\n

El segundo problema que UAC tuvo que tratar fue que los usuarios a veces necesitan derechos administrativos para realizar operaciones como, por ejemplo, instalar software, cambiar la hora del sistema y abrir puertos en el firewall.<\/p>\n

La soluci\u00f3n de UAC para estos problemas es ejecutar la mayor\u00eda de las aplicaciones con derechos de usuario est\u00e1ndar, obviar la necesidad de los derechos de administrador todo el tiempo y animar a los programadores de software a crear aplicaciones que se ejecuten con derechos de usuario est\u00e1ndar. UAC alcanza estos objetivos al requerir derechos administrativos con menor frecuencia, habilitar las aplicaciones heredadas para que se ejecuten con derechos de usuario est\u00e1ndar, haciendo que sea adecuado para los usuarios est\u00e1ndar el acceso a los derechos administrativos cuando los necesitan, y habilitar incluso a los usuarios administrativos para que ejecuten como si fueran usuarios est\u00e1ndar.<\/p>\n

Ejecuci\u00f3n como usuario est\u00e1ndar<\/strong><\/p>\n

Durante una auditor\u00eda completa de todas las operaciones administrativas durante el desarrollo de Windows Vista se identificaron muchas que se podr\u00edan habilitar para los usuarios est\u00e1ndar sin poner en peligro la seguridad del sistema. Por ejemplo, incluso las corporaciones que adoptaron cuentas de usuario est\u00e1ndar para sus sistemas de escritorio de Windows XP no pudieron quitar a sus usuarios que viajan del grupo Administradores por la \u00fanica raz\u00f3n de que Windows XP no diferencia entre cambiar la zona horaria y cambiar la hora del sistema. Un usuario de equipo port\u00e1til que desea configurar la zona horaria local para que sus citas se muestren correctamente en su calendario cuando viaja debe tener el privilegio “Cambiar la hora del sistema” (denominada internamente SeSystemTimePrivilege) que, de forma predeterminada, s\u00f3lo se concede a administradores.<\/p>\n

La hora se usa normalmente en protocolos de seguridad como Kerberos, pero la zona horaria s\u00f3lo afecta a la manera en la que se muestra la hora, de modo que Windows Vista agrega un privilegio nuevo, “Cambiar la zona horaria” (SeTimeZonePrivilege) y lo asigna al grupo Usuarios, como se ve en la figura 1. Esto hace posible que en muchas corporaciones los usuarios de equipo port\u00e1til trabajen bajo cuentas de usuario est\u00e1ndar.<\/p>\n

\"image\"<\/a>\u00a0<\/p>\n

Windows Vista tambi\u00e9n permite a los usuarios est\u00e1ndar configurar los valores WEP cuando se conectan a redes inal\u00e1mbricas, crean conexiones VPN, cambian la configuraci\u00f3n de administraci\u00f3n de energ\u00eda e instalan actualizaciones cr\u00edticas de Windows. Adem\u00e1s, incorpora la configuraci\u00f3n de directivas de grupo que permite a los usuarios est\u00e1ndar instalar controladores de impresora y otros dispositivos aprobados por administradores de TI e instalar controles ActiveX\u00ae<\/sup> de los sitios aprobados por el administrador.<\/p>\n

\u00bfQu\u00e9 ocurre con las aplicaciones de l\u00ednea de negocio y consumidor que no se ejecutan correctamente en cuentas de usuario est\u00e1ndar? Si bien algunos programas de software requieren leg\u00edtimamente derechos administrativos, muchos programas almacenan innecesariamente datos de usuario en ubicaciones globales del sistema. Microsoft recomienda que los instaladores de aplicaciones globales que esperan ejecutar con derechos administrativos creen un directorio en el directorio %Archivos de programa% para almacenar los archivos ejecutables de la aplicaci\u00f3n y los datos auxiliares y creen una clave en HKEY_LOCAL_EQUIPO\\Software para la configuraci\u00f3n de su aplicaci\u00f3n. Cuando se ejecuta una aplicaci\u00f3n, se puede ejecutar en diferentes cuentas de usuario y, por tanto, deber\u00eda almacenar datos de usuario espec\u00edficos en el directorio % AppData % por usuario y guardar la configuraci\u00f3n por usuario en el perfil de Registro del usuario en HKEY_CURRENT_USER\\ Software. Las cuentas de usuario est\u00e1ndar no tienen acceso de escritura al directorio %Archivos de programa% ni HKEY_LOCAL_MACHINE\\Software pero, debido a que la mayor\u00eda de los sistemas de Windows son de un \u00fanico usuario y la mayor\u00eda de los usuarios han sido administradores hasta Windows Vista, las aplicaciones que guardan incorrectamente datos de usuario y configuraci\u00f3n en estas ubicaciones funcionan de todos modos.<\/p>\n

Windows Vista permite que estas aplicaciones heredadas se ejecuten en cuentas de usuario est\u00e1ndar a trav\u00e9s de la ayuda del sistema de archivos y de la virtualizaci\u00f3n del espacio de nombres del Registro. Cuando una aplicaci\u00f3n modifica una ubicaci\u00f3n global del sistema en el Registro o el sistema de archivos y hay un error en dicha operaci\u00f3n porque se deniega el acceso, Windows redirecciona la operaci\u00f3n a un \u00e1rea por usuario; cuando la aplicaci\u00f3n lee desde una ubicaci\u00f3n global del sistema, Windows comprueba primero los datos en el \u00e1rea por usuario y, si no hay ninguno presente, permite el intento de lectura desde la ubicaci\u00f3n global.<\/p>\n

Para esta virtualizaci\u00f3n, Windows Vista trata un proceso como heredado si es de 32 bits (frente a 64 bits), no se ejecuta con derechos administrativos y no tiene un archivo de manifiesto que indique que se escribi\u00f3 para Windows Vista. No se virtualiza ninguna operaci\u00f3n cuyo origen no sea un proceso clasificado como heredado seg\u00fan esta definici\u00f3n, incluidos los accesos al recurso compartido de archivos de red. El estado de virtualizaci\u00f3n de un proceso se almacena como un indicador en su token, que es la estructura de datos del n\u00facleo que realiza el seguimiento del contexto de seguridad de un proceso, incluida su cuenta de usuario, las pertenencias a grupos y los privilegios.<\/p>\n

Puede consultar el estado de virtualizaci\u00f3n de un proceso si agrega la columna Virtualizaci\u00f3n a la p\u00e1gina Procesos del Administrador de tareas. La figura 2 muestra que la mayor\u00eda de los componentes de Windows Vista, incluido el Administrador de ventanas del escritorio (Dwm.exe), el subsistema en tiempo de ejecuci\u00f3n del cliente-servidor (Csrss.exe) y el Explorador, tienen la virtualizaci\u00f3n deshabilitada porque tienen un manifiesto de Windows Vista o se ejecutan con derechos administrativos y, por tanto, no admiten la virtualizaci\u00f3n. Internet Explorer\u00ae<\/sup> (iexplore.exe) tiene la virtualizaci\u00f3n habilitada porque puede alojar varias secuencias de comandos y controles ActiveX, y debe suponer que no se escribieron para funcionar correctamente con derechos de usuario est\u00e1ndar.<\/p>\n

\"image\"<\/a>\u00a0Las ubicaciones del sistema de archivos que est\u00e1n virtualizadas para procesos heredados son %Archivos de programa%, %ProgramData% y %SystemRoot%, excluyendo algunos subdirectorios espec\u00edficos. Sin embargo, cualquier archivo con una extensi\u00f3n ejecutable, entre las que se incluyen .exe, .bat, .scr, .vbs, entre otras, se excluye de la virtualizaci\u00f3n. Esto significa que los programas que se actualizan desde una cuenta de usuario est\u00e1ndar tienen un error en lugar de crear versiones privadas de sus archivos ejecutables que no son visibles para un administrador que ejecuta un programa de actualizaci\u00f3n global. Para agregar extensiones adicionales a la lista de excepciones, especif\u00edquelas en la siguiente clave del Registro y reinicie el equipo:<\/p>\n

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesLuafvParametersExcludedExtensionsAdd<\/p>\n

Use un tipo de cadena m\u00faltiple para delimitar varias extensiones y no incluya un punto inicial en el nombre de extensi\u00f3n.<\/p>\n

Las modificaciones a los directorios virtualizados por procesos heredados se redireccionan al directorio ra\u00edz virtual del usuario, %LocalAppData%\\VirtualStore. Por ejemplo, si un proceso virtualizado que se ejecuta en mi sistema crea C:\\Windows\\Application.ini, el archivo que se crea realmente es C:\\Users\\Markruss\\AppData\\Local\\VirtualStore\\Windows\\Application.ini. El componente Local de la ruta de acceso resalta el hecho de que los archivos virtualizados no ser\u00e1n itinerantes con el resto del perfil cuando la cuenta tiene un perfil m\u00f3vil.<\/p>\n

Si navega por el Explorador hasta un directorio que contiene archivos virtualizados, el Explorador muestra un bot\u00f3n con la etiqueta Archivos de compatibilidad en su barra de herramientas, tal como se muestra en la figura 3. Al hacer clic en el bot\u00f3n, navegar\u00e1 hasta el subdirectorio de VirtualStore correspondiente para mostrarle los archivos virtualizados.\"image\"<\/a><\/p>\n

La figura 4 muestra c\u00f3mo el controlador de filtros de virtualizaci\u00f3n de archivos UAC (%SystemRoot%\\System32\\Drivers\\Luafv.sys) implementa la virtualizaci\u00f3n del sistema de archivos. Debido a que se trata de un controlador de filtros del sistema de archivos, ve todas las operaciones del sistema de archivos pero s\u00f3lo implementa la funcionalidad para operaciones desde procesos heredados. Puede ver que cambia la ruta del archivo de destino para un proceso heredado que crea un archivo en una ubicaci\u00f3n global del sistema, pero no lo hace para un proceso que ejecuta una aplicaci\u00f3n de Windows Vista con derechos de usuario est\u00e1ndar. El proceso heredado cree que la operaci\u00f3n se realiza correctamente cuando realmente ha creado el archivo en una ubicaci\u00f3n completamente accesible para el usuario, pero los permisos predeterminados en el directorio de Windows deniegan el acceso a la aplicaci\u00f3n escrita para Windows Vista.<\/p>\n

\"image\"<\/a><\/p>\n

La virtualizaci\u00f3n del Registro se implementa de manera algo diferente a la virtualizaci\u00f3n del sistema de archivos. Entre las claves del Registro virtualizadas se incluyen la mayor parte de la rama HKEY_LOCAL_MACHINE\\Software, pero hay numerosas excepciones como, por ejemplo, las siguientes:<\/p>\n

HKLMSoftwareMicrosoftWindows HKLMSoftwareMicrosoftWindows NT HKLMSoftwareClasses<\/p>\n

S\u00f3lo se virtualizan las claves que est\u00e1n modificadas com\u00fanmente por aplicaciones heredadas pero que no presentan problemas de compatibilidad ni interoperabilidad. Windows redirecciona las modificaciones de claves virtualizadas por una aplicaci\u00f3n heredada a la ra\u00edz virtual del Registro de un usuario en HKEY_CURRENT_USER\\Software\\Classes\\VirtualStore. La clave se encuentra en el sub\u00e1rbol Classes del usuario, %LocalAppData%\\Microsoft\\Windows\\UsrClass.dat que, como cualquier otro elemento de datos de archivo virtualizado, no ser\u00e1 itinerante con un perfil de usuario m\u00f3vil.<\/p>\n

En lugar de mantener una lista fija de ubicaciones virtualizadas como lo hace Windows para el sistema de archivos, el estado de virtualizaci\u00f3n de una tecla se almacena como un indicador, REG_ KEY_DONT_VIRTUALIZE, en la propia clave. La utilidad Reg.exe puede mostrar el indicador as\u00ed como los otros dos indicadores relacionados con la virtualizaci\u00f3n, REG_KEY_ DONT_SILENT_FAIL y REG_KEY_ RECURSE_FLAG, como se ve en la figura 5. Cuando se define REG_KEY_DONT_SILENT_FAIL y la clave no est\u00e1 virtualizada (REG_KEY_DONT_VIRTUALIZE est\u00e1 definida), a una aplicaci\u00f3n heredada a la que se denegar\u00eda acceso para realizar una operaci\u00f3n en la clave se le concede en su lugar cualquier acceso que el usuario tiene a la clave en lugar de las que la aplicaci\u00f3n ha solicitado. REG_KEY_RECURSE_FLAG indica si las nuevas subclaves heredan los indicadores de virtualizaci\u00f3n del principal en lugar de \u00fanicamente los indicadores predeterminados.<\/p>\n

\"image\"<\/a><\/p>\n

En la figura 6 se muestra c\u00f3mo el Administrador de configuraci\u00f3n implementa la virtualizaci\u00f3n del Registro y administra el Registro en el n\u00facleo del sistema operativo, Ntoskrnl.exe. Al igual que con la virtualizaci\u00f3n del sistema de archivos, se redirecciona un proceso heredado que crea una subclave de una clave virtualizada a la ra\u00edz virtual del Registro del usuario pero a un proceso de Windows Vista se le deniega el acceso por permisos predeterminados.<\/p>\n

Adem\u00e1s del sistema de archivos y de la virtualizaci\u00f3n del Registro, algunas aplicaciones requieren ayuda adicional para ejecutarse correctamente con derechos de usuario est\u00e1ndar. Por ejemplo, una aplicaci\u00f3n que prueba la cuenta en la que se ejecuta para la pertenencia al grupo Administradores puede funcionar, pero no se ejecutar\u00e1 si no se encuentra en dicho grupo. Por tanto, Windows Vista define varias correcciones de compatibilidad (shim) de aplicaciones para que dichas aplicaciones funcionen de todos modos. Las correcciones de compatibilidad (shim) que se aplican a las aplicaciones heredadas para el funcionamiento con derechos est\u00e1ndar se muestran en la figura 7<\/a>. Los profesionales de TI corporativos pueden usar herramientas como el kit de herramientas de compatibilidad de aplicaciones (ACT, disponible en technet.microsoft.com\/windowsvista\/aa905066.aspx) y su utilidad Standard User Analyzer (SUA) o LUA Buglight<\/a> de Aaron Margosis para identificar los requisitos de correcciones de compatibilidad (shim) para su aplicaciones de l\u00ednea de negocio. Asignan correcciones de compatibilidad (shim) a una aplicaci\u00f3n mediante el Administrador de compatibilidad, que tambi\u00e9n forma parte del ACT y, a continuaci\u00f3n, implementan la base de datos de compatibilidad resultante (archivo .sdb) a sus escritorios mediante la directiva de grupo. Tenga en cuenta que, si fuera necesario, se puede deshabilitar la virtualizaci\u00f3n por completo para un sistema que usa una configuraci\u00f3n de directiva de seguridad local.<\/p>\n

Efectos de la virtualizaci\u00f3n<\/strong><\/p>\n

Puede cambiar el estado de la virtualizaci\u00f3n de un proceso si selecciona Virtualizaci\u00f3n del men\u00fa contextual que aparece al hacer clic con el bot\u00f3n secundario en el Administrador de tareas. En la figura A se muestra el comportamiento de un s\u00edmbolo del sistema cuando cambia su estado de virtualizaci\u00f3n. Empieza con la virtualizaci\u00f3n deshabilitada porque tiene un manifiesto de Windows Vista. Debido a que se ejecuta con derechos de usuario est\u00e1ndar, no puede crear un archivo en el directorio \\Windows pero, despu\u00e9s de que se virtualiza mediante el Administrador de tareas, parece que crea el archivo correctamente. Cuando su virtualizaci\u00f3n vuelve a su estado deshabilitado, no encuentra el archivo, que en realidad est\u00e1 en el almac\u00e9n virtual del usuario.<\/p>\n

\"image\"<\/a>\u00a0<\/p>\n

Modo de aprobaci\u00f3n del administrador<\/strong><\/p>\n

Aunque los usuarios ejecutan \u00fanicamente programas compatibles con derechos de usuario est\u00e1ndar, algunas operaciones todav\u00eda requieren derechos administrativos. La inmensa mayor\u00eda de las instalaciones de software requieren derechos de administrador para crear directorios y claves de Registro en ubicaciones globales del sistema o para instalar servicios o controladores de dispositivos. La modificaci\u00f3n de la configuraci\u00f3n global del sistema de aplicaciones y Windows tambi\u00e9n requiere derechos administrativos, al igual que la caracter\u00edstica de control parental de Windows Vista. Ser\u00eda posible realizar la mayor parte de estas operaciones si se cambia a una cuenta de administraci\u00f3n dedicada; pero el inconveniente de hacerlo es que la mayor\u00eda de los usuarios permanecer\u00eda en la cuenta administrativa para realizar sus tareas diarias.<\/p>\n

Por tanto, Windows Vista incluye la funcionalidad mejorada “ejecutar como” de modo que los usuarios est\u00e1ndar pueden iniciar procesos de manera conveniente con derechos administrativos. Esta funcionalidad requer\u00eda ofrecer a las aplicaciones una manera de identificar las operaciones para las que el sistema puede obtener derechos administrativos en nombre de la aplicaci\u00f3n seg\u00fan sea necesario, lo cual describir\u00e9 en breve.<\/p>\n

Adem\u00e1s, para que los usuarios que act\u00faan como administradores del sistema puedan ejecutar con derechos de usuario est\u00e1ndar, pero sin tener que especificar nombres de usuario y contrase\u00f1as cada vez que desean tener acceso a derechos administrativos, Windows Vista presenta el Modo de aprobaci\u00f3n de administrador (AAM). Esta caracter\u00edstica crea dos identidades para el usuario al iniciar una sesi\u00f3n: una, con derechos de usuario est\u00e1ndar y otra, con derechos administrativos. Puesto que cada usuario de un sistema de Windows Vista es un usuario est\u00e1ndar o ejecuta la mayor\u00eda de las veces como usuario est\u00e1ndar en AAM, los programadores deben suponer que todos los usuarios de Windows son usuarios est\u00e1ndar, lo que dar\u00e1 lugar a m\u00e1s programas trabajando con derechos de usuario est\u00e1ndar sin virtualizaci\u00f3n o correcciones de compatibilidad (shim).<\/p>\n

La concesi\u00f3n de derechos administrativos a un proceso se denomina elevaci\u00f3n. Cuando la realiza una cuenta de usuario est\u00e1ndar, se denomina elevaci\u00f3n de supervisi\u00f3n continua (OTS) porque requiere la entrada de credenciales para una cuenta que es miembro del grupo del administrador, algo que ha completado generalmente otro usuario escribiendo mientras supervisa al usuario est\u00e1ndar. Una elevaci\u00f3n realizada por un usuario de AAM se denomina elevaci\u00f3n de consentimiento porque el usuario s\u00f3lo tiene que aprobar la asignaci\u00f3n de sus derechos administrativos.<\/p>\n

Windows Vista considera administrador a un usuario si dicho usuario es miembro de cualquier grupo del tipo administrador que se incluye en la lista de la figura 8<\/a>. Muchos de los grupos incluidos en la lista se usan s\u00f3lo en sistemas unidos por un dominio y que no conceden directamente derechos administrativos locales a los usuarios pero les permiten modificar la configuraci\u00f3n para todo el dominio. Si un usuario es miembro de cualquiera de esos grupos, pero no del grupo Administradores real, el usuario obtiene acceso a sus derechos administrativos mediante elevaciones OTS en lugar de mediante elevaciones de consentimiento.<\/p>\n

Cuando inicia sesi\u00f3n un usuario que pertenece a uno de los grupos incluidos en una lista, Windows Vista crea un token que representa la versi\u00f3n del usuario est\u00e1ndar de la identidad administrativa del usuario. Al nuevo token se le quitan todos los privilegios asignados al usuario excepto los incluidos en una lista de la figura 9<\/a>, que son los privilegios de usuario est\u00e1ndar predeterminados. Adem\u00e1s, cualquiera de los grupos de tipo administrador est\u00e1 marcado con el indicador USE_FOR_DENY_ONLY en el nuevo token. La figura 10 muestra Sysinternals Process Explorer (una herramienta de administraci\u00f3n de procesos que se puede descargar desde la direcci\u00f3n microsoft .com\/technet\/sysinternals<\/a>) y que muestra los privilegios y las pertenencias a grupos de un proceso que se ejecuta con derechos administrativos a la izquierda y sin derechos de administrador a la derecha. (Para impedir un uso involuntario, el modelo de seguridad de Windows requiere que se habilite un privilegio con el indicador deshabilitado para poder usarlo).<\/p>\n

\"image\"<\/a><\/p>\n

Un grupo con el indicador deny-only \u00fanicamente se puede usar para denegar al usuario el acceso a un recurso, nunca admitirlo, solucionando una carencia en la seguridad que se podr\u00eda crear si, en cambio, el grupo se eliminase por completo. Por ejemplo, si un archivo ten\u00eda una lista de control de acceso (ACL) que deneg\u00f3 todo el acceso al grupo Administradores pero concedi\u00f3 alg\u00fan acceso a otro grupo al que pertenece el usuario, a \u00e9ste se le conceder\u00eda acceso si el grupo de administradores estuviera ausente del token, ofreciendo a la versi\u00f3n de usuario est\u00e1ndar de la identidad del usuario una mayor acceso que a su identidad de administrador.<\/p>\n

Los sistemas independientes, que son t\u00edpicamente equipos dom\u00e9sticos, y los sistemas unidos por un dominio tratan el acceso de AAM por usuarios remotos de manera diferente debido a que los equipos conectados por un dominio pueden usar grupos administrativos de dominio en sus permisos de recursos. Cuando un usuario tiene acceso a un recurso compartido de archivos de un equipo independiente, Windows solicita la identidad de usuario est\u00e1ndar del usuario remoto pero en los sistemas unidos por un dominio, Windows respeta todas las pertenencias a grupos de dominio del usuario al solicitar la identidad administrativa del usuario.<\/p>\n

Acceso \u00fatil a los derechos administrativos<\/strong><\/p>\n

Hay varias maneras para que el sistema y las aplicaciones identifiquen una necesidad de derechos administrativos. Una que aparece en la IU del Explorador es la opci\u00f3n de acceso directo y la entrada de men\u00fa contextual “Ejecutar como administrador”. Estos elementos incluyen un icono con forma de escudo que deber\u00eda colocarse en cualquier bot\u00f3n o elemento de men\u00fa que dar\u00eda lugar a una elevaci\u00f3n de derechos cuando est\u00e9 seleccionado. Al elegir la entrada “Ejecutar como administrador”, el Explorador llama a la API de ShellExecute con el verbo “runas”.<\/p>\n

La inmensa mayor\u00eda de los programas de instalaci\u00f3n requiere derechos administrativos, de modo que el cargador de im\u00e1genes, que empieza el inicio de un archivo ejecutable, incluye el c\u00f3digo de detecci\u00f3n del instalador para identificar probables instaladores heredados. Parte de la heur\u00edstica que usa es tan sencilla como detectar si la imagen tiene las palabras configuraci\u00f3n, instalaci\u00f3n o actualizaci\u00f3n en su nombre de archivo o informaci\u00f3n de versi\u00f3n interna; las m\u00e1s sofisticadas implican la exploraci\u00f3n de secuencias de byte en el archivo ejecutable que son comunes a utilidades de terceros de contenedor de instalaci\u00f3n.<\/p>\n

El cargador de im\u00e1genes tambi\u00e9n llama a la biblioteca de compatibilidad de aplicaciones (appcompat) para ver si el archivo ejecutable de destino requiere derechos de administrador. La biblioteca mira en la base de datos de compatibilidad de aplicaciones para ver si el archivo ejecutable tiene los indicadores de compatibilidad RequireAdministrator o RunAsInvoker asociados a \u00e9l.<\/p>\n

La manera m\u00e1s com\u00fan de que un archivo ejecutable solicite derechos administrativos es incluir una etiqueta requestedElevationLevel en su archivo de manifiesto de aplicaci\u00f3n. Los manifiestos son archivos XML que contienen informaci\u00f3n complementaria acerca de una imagen. Se presentaron en Windows XP como una manera de identificar las dependencias en los ensamblados de Microsoft .NET Framework y DLL en paralelo. La presencia del elemento trustInfo en un manifiesto (que se puede consultar en el volcado de cadenas extra\u00eddo de Firewallsettings.exe a continuaci\u00f3n), indica un archivo ejecutable que se escribi\u00f3 para Windows Vista y los nidos del elemento requestedElevationLevel incluidos. El atributo del nivel del elemento puede tener uno de los tres valores siguientes: asInvoker, highestAvailable y requireAdministrator.<\/p>\n

<trustInfo xmlns=\u201durn:schema-microsoft-com:asm.v3\u201d> <security> <requestedPrivileges> <requestedExecutionLevel Level=\u201drequireAdministrator\u201d uiAccess=\u201dfalse\u201d\/> <\/requestedPrivileges> <\/security> <\/trustInfo><\/p>\n

Los archivos ejecutables sin ninguna necesidad de derechos administrativos, como Notepad.exe, especifican el valor asInvoker. Algunos archivos ejecutables esperan que los administradores siempre deseen el m\u00e1ximo acceso, de manera que usen el valor highestAvailable. A un usuario que ejecuta un archivo ejecutable con dicho valor se le pedir\u00e1 elevar s\u00f3lo si ejecuta en AAM o si se considera un administrador seg\u00fan las reglas definidas anteriormente y debe elevar para tener acceso a sus derechos administrativos. Regedit.exe, Mmc.exe y Eventvwr.exe son ejemplos de aplicaciones que usan highestAvailable. Por \u00faltimo, requireAdministrator siempre produce una solicitud de elevaci\u00f3n y se usa por cualquier archivo ejecutable que tenga un error al operar sin derechos administrativos.<\/p>\n

Las aplicaciones de accesibilidad especifican “true” para el atributo uiAccess con el fin de controlar la entrada de ventana de procesos elevados y tambi\u00e9n deben estar firmadas y en una de las distintas ubicaciones seguras, entre las que se incluyen %SystemRoot% y %Archivos de programa%, para obtener dicho poder.<\/p>\n

Una manera sencilla de determinar los valores especificados por un archivo ejecutable es ver su manifiesto con la utilidad Sysinternals Sigcheck, tal como se muestra a continuaci\u00f3n:<\/p>\n

sigcheck \u2013m <executable><\/p>\n

La ejecuci\u00f3n de una imagen que solicita derechos administrativos hace que el Servicio de informaci\u00f3n de aplicaciones (tambi\u00e9n conocido como AIS, incluido en %SystemRoot%\\System32\\Appinfo.dll), que se ejecuta dentro de un proceso de host de servicio (%SystemRoot%\\System32\\Svchost .exe), inicie Consent.exe (%SystemRoot%\\System32\\Consent.exe). El consentimiento captura un mapa de bits de la pantalla, le aplica un efecto de atenuaci\u00f3n, conmuta a un escritorio al que s\u00f3lo se tiene acceso por la cuenta del sistema local, pinta el mapa de bits como el segundo plano y muestra un cuadro de di\u00e1logo de elevaci\u00f3n que contiene informaci\u00f3n acerca del archivo ejecutable. La visualizaci\u00f3n en un escritorio independiente impide que cualquier malware presente en la cuenta del usuario modifique el aspecto del cuadro de di\u00e1logo.<\/p>\n

\"image\"<\/a> \"image\"<\/a> \"image\"<\/a><\/p>\n

Figura 11 Cuadros de di\u00e1logo de elevaci\u00f3n de OTS<\/p>\n

Si una imagen es un componente de Windows firmado digitalmente por Microsoft y la imagen se encuentra en el directorio del sistema Windows, el cuadro de di\u00e1logo muestra una banda azul en la parte superior, tal como se muestra en la figura 11. La banda gris (el cuadro de di\u00e1logo intermedio) es para las im\u00e1genes firmadas digitalmente por alguien ajeno a Microsoft y la banda naranja (el cuadro de di\u00e1logo inferior) es para im\u00e1genes sin firmar. El cuadro de di\u00e1logo de elevaci\u00f3n muestra el icono, la descripci\u00f3n y el editor de la imagen para las im\u00e1genes firmadas digitalmente. Para las im\u00e1genes sin firmar, s\u00f3lo muestra un icono gen\u00e9rico, el nombre del archivo y “Editor no identificado”. Esto hace que para el malware sea m\u00e1s dif\u00edcil imitar el aspecto de software leg\u00edtimo. El bot\u00f3n Detalles de la parte inferior del cuadro de di\u00e1logo se expande para mostrar la l\u00ednea de comandos que se pasar\u00e1 al archivo ejecutable si se inicia. El cuadro de di\u00e1logo de consentimiento de AAM, que se muestra en la figura 12, es similar pero, en lugar de pedir credenciales de administrador, tiene los botones Continuar y Cancelar.<\/p>\n

\"image\"<\/a><\/p>\n

Si un usuario rechaza una elevaci\u00f3n, Windows devuelve un error de acceso denegado al proceso que empez\u00f3 el inicio. Cuando un usuario acepta una elevaci\u00f3n al especificar credenciales de administrador o al hacer clic en Continuar, AIS llama a CreateProcessAsUser para iniciar el proceso con la identidad administrativa apropiada. Aunque AIS sea t\u00e9cnicamente el padre del proceso elevado, AIS usa nuevo soporte en la API de CreateProcessAsUser que establece el Id. de proceso principal de dicho proceso al del proceso que lo inici\u00f3 originalmente (consulte la figura 13). Ese es el motivo por el que los procesos elevados no aparecen como hijos del proceso de alojamiento de servicio de AIS en herramientas como Process Explorer que muestra \u00e1rboles del proceso.<\/p>\n

\"image\"<\/a><\/p>\n

Aunque los cuadros de di\u00e1logo de elevaci\u00f3n aparezcan en un escritorio seguro independiente, de forma predeterminada, los usuarios no tienen ninguna manera de comprobar que est\u00e1n visualizando un cuadro de di\u00e1logo leg\u00edtimo y no uno presentado por malware. Eso no supone un problema para AAM porque el malware no puede obtener derechos administrativos con un cuadro de di\u00e1logo de consentimiento falso. Sin embargo, el malware podr\u00eda esperar la elevaci\u00f3n OTS de un usuario est\u00e1ndar, interceptarlo y usar un cuadro de di\u00e1logo de caballo de Troya para capturar las credenciales de administrador. Con dichas credenciales pueden obtener acceso a la cuenta del administrador e infectarla.<\/p>\n

Por este motivo, las elevaciones de OTS no son nada recomendables en entornos corporativos. Para deshabilitar elevaciones de OTS, y as\u00ed reducir las llamadas al servicio de soporte t\u00e9cnico, ejecute el editor de directivas de seguridad local (Secpol.msc) y configure “Control de cuentas de usuario: comportamiento del indicador de elevaci\u00f3n para los usuarios est\u00e1ndar” en “Rechaza solicitudes de elevaci\u00f3n autom\u00e1ticamente”.<\/p>\n

Los usuarios de equipos dom\u00e9sticos conscientes de la seguridad deben configurar las elevaciones de OTS para requerir una secuencia de aviso de seguridad (SAS) que el malware no pueda interceptar ni simular. Para configurar SAS, ejecute el Editor de directivas de grupo (Gpedit.msc), navegue hasta Configuraci\u00f3n del equipo | Plantillas administrativas | Componentes de Windows | Interfaz de usuario de credenciales, y habilite “Requerir ruta de acceso de confianza para la entrada de credenciales”. Despu\u00e9s que hacerlo, deber\u00e1 presionar Ctrl+Alt+Supr para tener acceso al cuadro de di\u00e1logo de elevaci\u00f3n.<\/p>\n

Aislamiento de los procesos elevados<\/strong><\/p>\n

Windows Vista coloca una barrera alrededor de los procesos elevados para protegerlos de la ejecuci\u00f3n de malware que se ejecuta en el mismo escritorio con derechos de usuario est\u00e1ndar. Sin una barrera, el malware podr\u00eda controlar una aplicaci\u00f3n administrativa envi\u00e1ndole entradas de ventana y mouse sintetizadas mediante mensajes de ventana. Y, aunque el modelo de seguridad de Windows est\u00e1ndar impide que la ejecuci\u00f3n de malware en un proceso con derechos de usuario est\u00e1ndar modifique un proceso elevado que se ejecute como un usuario diferente, no impide que la ejecuci\u00f3n de malware como la versi\u00f3n de derechos est\u00e1ndar de un usuario administrativo abra los procesos elevados del usuario, inyect\u00e1ndoles c\u00f3digo, e iniciando subprocesos en ellos para ejecutar el c\u00f3digo inyectado.<\/p>\n

El escudo de Windows Vista para mensajes de ventana se denomina aislamiento de privilegios en la interfaz de usuario (UIPI). Se basa en el nuevo mecanismo de integridad de Windows que Windows Vista usa tambi\u00e9n como barrera alrededor de procesos elevados. En este nuevo modelo de seguridad, todos los procesos y los objetos tienen niveles de integridad, y la directiva de integridad de un objeto puede restringir los accesos que de otro modo se conceder\u00edan a un proceso mediante el modelo de seguridad de control de acceso discrecional (DAC) de Windows.<\/p>\n

Los niveles de integridad (IL) est\u00e1n representados por identificadores de seguridad (SID), que tambi\u00e9n representan usuarios y grupos, donde el nivel est\u00e1 codificado en el identificador relativo del SID (RID). En la figura 14<\/a> se muestra el nombre para mostrar, el SID y la versi\u00f3n hexadecimal del RID del SID para los cuatro IL principales. Los n\u00fameros hexadecimales revelan intervalos de 0x1000 entre cada nivel que permite el uso de los niveles intermedios por las aplicaciones de accesibilidad de IU as\u00ed como el crecimiento futuro.<\/p>\n

En la figura 15<\/a> se incluye una lista las directivas de IL de objeto y los tipos de acceso que restringen, que corresponden a los accesos gen\u00e9ricos definidos para un objeto. Por ejemplo, No-Write-Up impide que un proceso de IL inferior obtenga cualquiera de los accesos representados por los accesos de GENERIC_WRITE. La directiva predeterminada para la mayor\u00eda de los objetos, entre los que se incluyen archivos y claves de registro, es No-Write-Up, que impide que un proceso obtenga acceso de escritura a objetos que tengan un IL superior a \u00e9l mismo, incluso si la lista de control de acceso discrecional (DACL) del objeto concede al usuario dicho acceso. Los \u00fanicos objetos con una directiva diferente son los objetos de proceso y subproceso. Su directiva, No-Write-Up m\u00e1s No-Read-Up, detiene un proceso que se ejecuta en un IL inferior para que no inyecte c\u00f3digo ni lea datos, tales como contrase\u00f1as, fuera de un proceso que tenga un IL superior.<\/p>\n

Windows asigna a cada proceso un IL que coloca en el token del proceso junto con los SID de los grupos a los que pertenece el usuario que ejecuta el proceso. En la figura 16<\/a> se incluye una lista con los ejemplos de los procesos asignados a diferentes IL. Los procesos suelen heredar el IL de su padre pero un proceso tambi\u00e9n puede iniciar otro proceso en un IL diferente, como lo hace AIS cuando inicia un proceso elevado. Es posible ver los niveles de integridad del proceso con la utilidad Whoami integrada si se especifica la opci\u00f3n \/all, o bien mediante Sysinternals Process Explorer o AccessChk. Process Explorer puede mostrar los IL del proceso con la adici\u00f3n de la columna de nivel de integridad.<\/p>\n

Cada objeto asegurable tiene un IL expl\u00edcito o impl\u00edcito. El proceso, el subproceso y los objetos de token siempre tienen un IL expl\u00edcitamente asignado que suele ser el mismo que el IL almacenado en el token del proceso correspondiente. La mayor\u00eda de los objetos no tienen IL expl\u00edcito y, por tanto, se vuelven de manera predeterminada a un IL de medio. Los \u00fanicos objetos creados con un IL distinto al medio son los objetos creados por un proceso que se ejecuta en el IL bajo, que por tanto tiene un IL bajo. Puede usar la herramienta iCacls integrada (%SystemRoot%\\System32\\iCacls.exe) para ver los IL de archivos y la utilidad Sysinternals AccessChk para ver los ILs de archivos, claves de Registro, servicios y procesos. La figura 17 revela que el IL de un directorio que necesita ser accesible por Internet Explorer de modo protegido es bajo.<\/p>\n

\"image\"<\/a>\u00a0<\/p>\n

Si un objeto tiene un IL expl\u00edcito, se almacena en una entrada de control de acceso (ACE) de un tipo nuevo para Windows Vista, la ACE de etiqueta, en la lista de sistema de acceso (SACL) del descriptor de seguridad del objeto (consulte la figura 18). El SID de la ACE corresponde al IL del objeto y los indicadores de ACE codifican la directiva de integridad del objeto. Antes de Windows Vista, las SACL almacenaban \u00fanicamente las ACE de auditor\u00eda, que requieren el privilegio “Administrar registro de seguridad y auditor\u00eda” (SeSecurityPrivilege), pero la lectura de una ACE de etiqueta s\u00f3lo requiere acceso de permisos de lectura (READ_CONTROL). Para que un proceso modifique el IL de un objeto, debe tener acceso de Cambiar el propietario (WRITE_OWNER) para el objeto y un IL que sea igual o mayor que el objeto, y el proceso s\u00f3lo puede establecer el IL como su propio IL o inferior. El nuevo privilegio “Modificar la etiqueta de un objeto” (SeRelabelPrivilege) ofrece a un proceso la capacidad de cambiar el IL de cualquier objeto al que el proceso tiene acceso e incluso elevar el IL por encima del IL propio del proceso, pero de forma predeterminada no se asigna dicho privilegio a ninguna cuenta.<\/p>\n

\"image\"<\/a><\/p>\n

Cuando un proceso intenta abrir un objeto, se produce la comprobaci\u00f3n de integridad antes de la comprobaci\u00f3n de DACL de Windows est\u00e1ndar en la funci\u00f3n SeAccessCheck del n\u00facleo. Dadas las directivas de integridad predeterminadas, un proceso s\u00f3lo puede abrir un objeto para acceso de escritura si su IL es igual o mayor que el IL del objeto y la DACL tambi\u00e9n concede al proceso los accesos que desea. Por ejemplo, un proceso de IL bajo no puede abrir un proceso de IL medio para acceso de escritura, incluso aunque el DACL conceda el acceso de escritura del proceso.<\/p>\n

Con la directiva de integridad predeterminada, los procesos pueden abrir cualquier objeto, a excepci\u00f3n de los objetos de proceso y subproceso, para acceso de lectura siempre que la DACL del objeto les conceda acceso de lectura. Eso significa que un proceso que se ejecuta en IL bajo puede abrir archivos accesibles para la cuenta de usuario en la que se ejecuta. Internet Explorer de modo protegido usa IL para ayudar a impedir que el malware lo infecte al modificar la configuraci\u00f3n de la cuenta de usuario, pero no impide que el malware lea documentos del usuario.<\/p>\n

Los objetos de proceso y subproceso son excepciones porque su directiva de integridad tambi\u00e9n incluye No-Read-Up. Eso significa que el IL de un proceso debe ser igual o superior al IL del proceso o subproceso que desea abrir y la DACL debe concederle los accesos que desea para que uno abierto sea correcto. Suponiendo que las DACL admitan el acceso deseado, la figura 19 muestra los accesos que los procesos que ejecutan en medio y bajo tienen a otros procesos y objetos.<\/p>\n

\"image\"<\/a><\/p>\n

El subsistema de mensajer\u00eda de Windows tambi\u00e9n respeta los niveles de integridad para implementar UIPI al impedir que un proceso env\u00ede todos los mensajes de ventanas informativas, salvo algunos, a las ventanas que son propiedad de un proceso con un IL superior. Eso no permite que los procesos de usuario est\u00e1ndar controlen la entrada en las ventanas de procesos elevados o que rompan un proceso elevado envi\u00e1ndole mensajes con formato incorrecto que desencadenen desbordamientos de b\u00fafer internos. Los procesos pueden elegir admitir que mensajes adicionales pasen la guardia al llamar a la API de ChangeWindowMessageFilter. UIPI tambi\u00e9n bloquea enlaces de ventana para que no afecten a las ventanas de procesos de IL superior de manera que el proceso de un usuario est\u00e1ndar no pueda registrar las pulsaciones de tecla que el usuario escribe en una aplicaci\u00f3n administrativa, por ejemplo.<\/p>\n

L\u00edmites de elevaciones y seguridad<\/strong><\/p>\n

Es importante ser consciente de que las elevaciones de UAC son comodidades y no l\u00edmites de seguridad. Un l\u00edmite de seguridad requiere que la directiva de seguridad dicte qu\u00e9 puede pasar a trav\u00e9s del l\u00edmite. Las cuentas de usuario son un ejemplo de l\u00edmite de seguridad en Windows porque un usuario no puede tener acceso a los datos que pertenecen a otro usuario sin tener el permiso de dicho usuario.<\/p>\n

Debido a que las elevaciones no son l\u00edmites de seguridad, no hay garant\u00eda de que un malware que se ejecute en un sistema con derechos de usuario no ponga en peligro un proceso elevado para obtener derechos administrativos. Por ejemplo, los cuadros de di\u00e1logo de elevaci\u00f3n s\u00f3lo identifican el archivo ejecutable que se elevar\u00e1; no dicen nada acerca de lo que har\u00e1 cuando se ejecute. El archivo ejecutable procesar\u00e1 los argumentos de la l\u00ednea de comandos, cargar\u00e1 archivos DLL, abrir\u00e1 archivos de datos y se comunicar\u00e1 con otros procesos. Cabe la posibilidad de que cualquiera de esas operaciones podr\u00eda admitir que malware pusiera en peligro el proceso elevado y obtuviera as\u00ed derechos administrativos.<\/p>\n

Reproducci\u00f3n en un recinto de IL bajo<\/strong><\/p>\n

Internet Explorer de modo protegido se ejecuta en IL bajo para crear una barrera alrededor del malware que quiz\u00e1 infecte a su proceso. Esto impide que malware cambie la configuraci\u00f3n de la cuenta del usuario y se instale en una ubicaci\u00f3n de inicio autom\u00e1tico. Puede usar la utilidad Sysinternals PsExec, junto con el conmutador -l, para iniciar los procesos arbitrarios en el IL bajo para explorar el recinto. En la figura B se muestra c\u00f3mo un s\u00edmbolo del sistema que se ejecuta en IL bajo no puede crear un archivo en el directorio temporal del usuario, que tiene un IL medio, pero puede hacerlo en el directorio temporal de Internet Explorer, que tiene un IL bajo.<\/p>\n

\"image\"<\/a><\/p>\n

Los procesos de AAM elevados son especialmente susceptibles de verse puestos en peligro porque se ejecutan en la misma cuenta de usuario que los procesos de derechos est\u00e1ndar del usuario de AAM y comparten el perfil del usuario. Muchas aplicaciones leen la configuraci\u00f3n y cargan las extensiones registradas en el perfil de un usuario, ofreciendo oportunidades para que se eleve el malware. Por ejemplo, los cuadros de di\u00e1logo de control comunes cargan las extensiones de Shell configuradas en la clave de Registro de un usuario (bajo HKEY_CURRENT_USER), de manera que el malware puede agregarse como una extensi\u00f3n para cargarse en cualquier proceso elevado que use dichos cuadros de di\u00e1logos.<\/p>\n

Incluso los procesos elevados de cuentas de usuario est\u00e1ndar pueden verse en peligro a causa del estado compartido. Todos los procesos que se ejecutan en una sesi\u00f3n de inicio comparten el espacio de nombres interno en el que Windows almacena objetos como, por ejemplo, eventos, exclusiones mutuas, sem\u00e1foros y memoria compartida. Si el malware sabe que un proceso elevado tratar\u00e1 de abrir y de leer un objeto de memoria compartido espec\u00edfico cuando se inicie el proceso, podr\u00eda crear el objeto con contenido que desencadene un desbordamiento del b\u00fafer para inyectar c\u00f3digo en el proceso elevado. Ese tipo de ataque es relativamente sofisticado pero su posibilidad impide que las elevaciones de OTS sean un l\u00edmite de seguridad.<\/p>\n

Lo fundamental es que las elevaciones se presentaron como una comodidad que anima a los usuarios que desean tener acceso a derechos administrativos para que ejecuten con derechos de usuario est\u00e1ndar de manera predeterminada. Los usuarios que desean que las garant\u00edas de un l\u00edmite de seguridad puedan equilibrar la comodidad usando una cuenta de usuario est\u00e1ndar para las tareas diarias y Cambio r\u00e1pido de usuario (FUS) a una cuenta de administrador dedicada para realizar las operaciones administrativas. Por otro lado, los usuarios que deseen renunciar a la seguridad en favor de la comunidad puede deshabilitar UAC en un sistema en el cuadro de di\u00e1logo Cuentas de usuario del Panel de control, pero deben ser conscientes de que esto deshabilita adem\u00e1s el Modo protegido de Internet Explorer.<\/p>\n

Conclusi\u00f3n<\/strong><\/p>\n

La ejecuci\u00f3n como usuario est\u00e1ndar tiene numerosos beneficios, entre los que se incluyen la ayuda para proteger los sistemas de da\u00f1os accidentales o deliberados, y de proteger los datos y la integridad de los usuarios que comparten un sistema del acceso no autorizado. Las tecnolog\u00edas y los distintos cambios de UAC tendr\u00e1n como resultado un cambio principal en el modelo de uso de Windows. Con Windows Vista, los usuarios de Windows pueden realizar por primera vez la mayor\u00eda de las tareas diarias y ejecutar la mayor parte del software usando derechos de usuario est\u00e1ndar, y muchas corporaciones pueden ahora implementar cuentas de usuario est\u00e1ndar.<\/p>\n

\n

Mark Russinovich<\/strong> es empleado t\u00e9cnico de Microsoft en la divisi\u00f3n de servicios y plataformas. Es coautor de Microsoft Windows Internals<\/em> (Microsoft Press, 2004) y orador frecuente en conferencias de programadores y TI. Se uni\u00f3 a Microsoft con la adquisici\u00f3n reciente de la compa\u00f1\u00eda que cofund\u00f3, Winternals Software. Tambi\u00e9n cre\u00f3 Sysinternals, donde public\u00f3 las utilidades Process Explorer, Filemon y Regmon<\/p>\n

\n

Extra\u00eddo del\u00a0June 2007<\/a>\u00a0n\u00famero de\u00a0TechNet Magazine<\/a>.<\/p>\n

\n","protected":false},"excerpt":{"rendered":"

Ya he hablado recientemente en una nota sobre esta nueva funcionalidad en Windows Vista, y…<\/p>\n","protected":false},"author":1,"featured_media":4291,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[13],"tags":[],"class_list":["post-106","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-vista-xp"],"_links":{"self":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts\/106","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=106"}],"version-history":[{"count":0,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts\/106\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/media\/4291"}],"wp:attachment":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=106"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=106"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=106"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}