Seguridad en Longhorn: Centrarse en privilegios mínimos

 

Keith Brown
DevelopMentor

Abril de 2004

Se aplica a:
   Compilación preliminar de "Longhorn" para desarrolladores profesionales (PDC) de 2003

Resumen: Longhorn promete ser una gran plataforma para aplicaciones con privilegios mínimos. Comience hoy escribiendo código administrado, en primer lugar. Al compilar aplicaciones de escritorio, hágalos compatibles con LUA (y use el Comprobador de aplicaciones de Windows para ayudar a comprobar el trabajo). (11 páginas impresas)

Contenido

El problema
Manifiestos de aplicación e implementación
LUA: cuenta de usuario con privilegios mínimos
Grupo de usuarios avanzados (en desuso)
OBJETIVO: Administración del impacto de la aplicación
PA: Administrador protegido
Aplicaciones administradas en Longhorn
Conjunto de permisos "Sin riesgo"
Herramientas
Resumen

He sido un defensor de la ejecución con privilegios mínimos. Muchos que me conocen han oído que los desarrolladores deben dejar de ejecutarse con privilegios administrativos mientras desarrollan código, si solo para ayudar a que se escriban más aplicaciones para que se ejecuten en entornos con privilegios mínimos. Así que estaba muy contento de escuchar en la Conferencia de desarrolladores profesionales de Microsoft 2003 (PDC) que uno de los objetivos principales de la próxima versión del sistema operativo Windows®, denominado "Longhorn", es facilitar la ejecución de los usuarios con privilegios mínimos.

El problema

Al comprar una copia de Microsoft Windows XP® Professional en su tienda de software local e instalarla en un equipo, el asistente para la instalación crea cuentas para usted y cualquier otra persona que use el equipo. Después de arrancar Windows XP, muestra una pantalla de bienvenida que muestra el nombre de cada usuario y les permite iniciar sesión. Cada uno de estos usuarios es de forma predeterminada un administrador de la máquina. ¿Por qué? Dado que la experiencia del usuario sería mala si no fuera así.

Los usuarios esperan poder instalar software en sus máquinas, pero no puede instalar el 90 % del software actual a menos que sea administrador. Los usuarios esperan que el software se ejecute sin bloquearse, pero el 70 % del software no se ejecutará correctamente a menos que el usuario sea administrador y ese es un número optimista. Lamentablemente, un gran número de estas aplicaciones producen un error en un entorno no administrativo simplemente porque toman decisiones deficientes sobre dónde guardar el estado de la aplicación. El directorio Archivos de programa no está pensado como un lugar para almacenar el estado. Es un lugar para almacenar programas: archivos ejecutables. El lugar para almacenar el estado de la aplicación se denomina perfil de usuario y, para almacenar el estado de usuario compartido, el perfil "Todos los usuarios" basta bastante bien. Las directrices del Programa de logotipos de Windows explican esto, pero la gran mayoría del software de Windows hoy en día se desarrolló sin tener en cuenta las directrices del logotipo de Windows.

Pero, ¿por qué, podría preguntar, si los usuarios quieren ejecutarse como usuarios que no son administradores, especialmente los usuarios domésticos? Bueno, si fuera realmente fácil de hacer, el usuario doméstico aprovecharía muchas ventajas. Malware (un virus, gusano u otro código malintencionado) le encanta tener privilegios administrativos. Navegar por la Web o leer el correo electrónico como administrador es simplemente peligroso en estos días. ¿Y tus hijos? ¿No sería bueno permitirles instalar y jugar juegos en su equipo doméstico sabiendo que no interrumpirán accidentalmente algo, instalar spyware o eliminar las limitaciones de clasificación de contenido que ha impuesto? Piense en ello de esta manera: la ejecución como administrador desactiva eficazmente la mayoría de las protecciones de seguridad proporcionadas por Windows. Los usuarios domésticos y corporativos no deben desactivar estas protecciones, especialmente cuando están conectados a Internet, que se ha convertido en un vecindario bastante peligroso.

La obtención de usuarios y los programas que ejecutan para vivir felizmente en un entorno con privilegios mínimos va a aumentar significativamente la seguridad de la plataforma Windows.

Manifiestos de aplicación e implementación

Una característica importante que presenta Longhorn es la noción de manifiestos de aplicación e implementación. El primero permite a los desarrolladores de aplicaciones indicar los permisos que requiere su aplicación para funcionar correctamente, y este último permite a los administradores especificar la cantidad de confianza que colocan en la aplicación. Hay mucho más que esto en estos manifiestos, pero quiero señalar que están disponibles para su uso por parte de aplicaciones administradas y no administradas, y una gran razón de su existencia es ayudar a los usuarios a ejecutar aplicaciones con el menor privilegio posible.

Para obtener más información sobre estos manifiestos, eche un vistazo al capítulo 1 del libro de Brent Rector Introducing "Longhorn" for Developers( Introducción a "Longhorn" para desarrolladores).

LUA: cuenta de usuario de Least-Privilege

LUA, o cuenta de usuario con privilegios mínimos, es un acrónimo que estoy seguro de que verá repetidas veces en presentaciones de Microsoft de ahora en adelante. Los moderadores del PDC 2003 a menudo pronuncian el acrónimo como "looah". No es nada elegante, ni siquiera nada nuevo. LUA hace referencia a la práctica de usar cuentas de usuario sin privilegios, tanto para usuarios interactivos como para servicios.

El equipo de Longhorn quiere simplificar la seguridad. Creen que debe haber dos niveles de acceso al sistema: privilegios mínimos y administrativos. Incluso han dejado de usar el grupo de usuarios avanzados (a los que se hace referencia en algunos círculos como "admin-lite") en Longhorn.

Con el grupo Usuarios avanzados, los desarrolladores de aplicaciones realmente necesitan tomar una decisión. Deben decidir cuál de los dos niveles de privilegios (LUA o administrativos) necesita su aplicación para Longhorn. Si la aplicación no necesita privilegios administrativos, debe escribirse cuidadosamente para que funcione con una cuenta con privilegios mínimos. Esto significa probar (y, una esperanza, incluso escribir el código) mediante cuentas de usuario normales. Por ejemplo, una aplicación LUA debe escribir archivos de datos en un lugar seguro, como el perfil de usuario, en lugar del árbol de directorio Archivos de programa. ¿Pero qué ocurre con las aplicaciones que no se reescribirán para Longhorn? ¿Qué ocurre si esas aplicaciones no se ejecutan bien con cuentas con privilegios mínimos incluso en Windows XP? Una característica de Longhorn denominada Application Impact Management (AIM) podría ayudar a esas aplicaciones a ejecutarse en LUA de todos modos, como verá en breve.

Grupo de usuarios avanzados (en desuso)

Si piensa en una cuenta administrativa con acceso "alto" y una cuenta de usuario normal con acceso "bajo", se puede decir que una cuenta de usuario avanzado tiene acceso "medio". El grupo Usuarios avanzados puede leer y escribir partes del sistema de archivos y el registro que normalmente están fuera de los límites de las cuentas con privilegios mínimos (es decir, las cuentas de usuario normales que no contienen pertenencia a grupos con privilegios, como administradores o usuarios avanzados). Muchas personas que intentaron ejecutarse como usuarios normales encontraron que tanto software falló que decidieron agregar sus cuentas al grupo usuarios avanzados, lo que corrigió casi todos los problemas que tenían. Pero ya no estaban funcionando con privilegios mínimos. Por ejemplo, en Windows XP, cualquier malware que se ejecute con este nivel de privilegio "medio" podrá poner en peligro otras aplicaciones almacenadas en el directorio Archivos de programa, reemplazar componentes COM de confianza por troyanos, etc. La próxima vez que el usuario se ejecute bajo su cuenta administrativa en una máquina tan comprometida, puede estar seguro de que el malware se ejecutará también a través de un troyano instalado anteriormente. Por lo tanto, no obtiene ninguna protección real ejecutándose como un usuario avanzado.

OBJETIVO: Administración del impacto de la aplicación

El equipo de Longhorn cree que la ejecución con privilegios mínimos es importante. Quieren que la pantalla de bienvenida contenga una lista de cuentas de usuario que constan principalmente de cuentas con privilegios mínimos. Pero también tienen sus pies en tierra en realidad. Al igual que un gran número de software importante hoy en día ignora completamente el Programa de logotipos de Windows, gran parte del software importante en el período de tiempo de Longhorn también puede ignorar la iniciativa LUA. Los desarrolladores de aplicaciones sin formato seguirán escribiendo software que lea y escriba archivos de datos desde el árbol de directorios Archivos de programa. También seguirán escribiendo datos del Registro en HKEY_LOCAL_MACHINE en lugar de HKEY_CURRENT_USER. El primero está fuera de los límites de escritura por parte de los usuarios normales, por lo que es preferible almacenar la configuración de la aplicación, si el registro debe usarse en absoluto.

Cuando Windows XP puede detectar que una aplicación necesita más privilegios (esto es poco frecuente, pero se produce ocasionalmente con programas de instalación), informará al usuario sin privilegios de que la aplicación requiera privilegios administrativos para ejecutarse y que aparezca convenientemente un cuadro de diálogo para recopilar el nombre de usuario y la contraseña de una cuenta de administrador. A continuación, el programa se ejecuta en la cuenta especificada. Pero esto no siempre funciona porque muchas aplicaciones no se escriben para instalarse en una cuenta y se usan en otra.

Longhorn toma un enfoque completamente diferente. En lugar de animar al usuario a elevar privilegios para que la aplicación pueda funcionar correctamente, Longhorn prefiere ejecutar la aplicación en LUA. ¿Pero qué ocurre cuando la aplicación intenta escribir en HKEY_LOCAL_MACHINE o en el árbol de directorios archivos de programa? Longhorn proporciona a la aplicación su propia vista virtualizada del recurso que intenta cambiar, mediante una estrategia de copia en escritura. Cuando la aplicación intenta escribir en un archivo en el directorio Archivos de programa, Longhorn le dará a la aplicación su propia copia privada del archivo y puede conectarse. De este modo, cualquier malware que se desenlaje en un escenario AIM podría intentar sobrescribir un ejecutable que se usa habitualmente en el árbol de directorio Archivos de programa, quizás WINWORD.EXE. Pero lo que terminará sobrescribiendo es una copia privada que solo puede ver el malware. La versión de WINWORD.EXE que el usuario ve seguirá siendo la versión original y sin contenido.

No confíes en AIM para ahorrarte. Escriba la aplicación para que se ejecute en LUA desde el primer día.

PA: Administrador protegido

Incluso si se corrigieron todas las aplicaciones en el período de tiempo de Longhorn para ejecutarse en LUA, todavía habrá aplicaciones que realmente requieran privilegios administrativos. Incluyen utilidades como el software de copia de seguridad, la desfragmentación de unidades de disco duro y el software de repartición, el software de administración empresarial y la lista continúa. Por lo tanto, en algún momento el usuario tendrá que usar una cuenta administrativa para realizar cierto trabajo. Y vamos a enfrentarlo, mucha gente ignorará el consejo para crear cuentas de LUA y simplemente ejecutarse como administradores todo el tiempo.

El equipo de Longhorn ha diseñado un esquema ordenado para ayudarle a protegerse cuando se ejecuta bajo una cuenta administrativa. Es una característica denominada Administrador protegido y, cuando está activada, siempre puede ejecutarse con una cuenta administrativa y sentirse razonablemente segura, ya que la gran mayoría de las aplicaciones que se ejecutan se ejecutarán con un token restringido especial, un token similar al que tendría en un escenario lua. Solo una aplicación que tenga "bendecido" o que su empresa haya implementado y designado como de confianza, se ejecutará con el token administrativo completo. Una manera de designar una aplicación como de confianza es firmar su manifiesto de implementación. ¿Por qué es esto útil? Déjame darle un ejemplo.

Un usuario que normalmente se ejecuta como administrador abre su cliente de correo electrónico de Longhorn y comienza a navegar por correo electrónico. Ella se encuentra a través de un pedazo de correo que vino de alguien que conoce, y abre un adjunto. Poco sabe que su amigo fue infectado recientemente por un gusano de correo electrónico, y este mensaje contiene malware. Cuando se ejecuta el malware, encuentra que tiene muy pocos privilegios en el sistema. No puede modificar nada en el árbol de directorio Archivos de programa. No puede cambiar los registros de objetos COM en HKEY_LOCAL_MACHINE. Esto no significa que no pueda hacer nada malo, pero la situación es mucho mejor de lo que habría sido si el malware se encontrara ejecutándose con privilegios administrativos.

Pero espera, ¿no dije que el usuario se estaba ejecutando como administrador cuando ejecutó la aplicación de correo electrónico? Sí, eso fue en realidad el caso. Pero la aplicación de correo electrónico no se designó como una aplicación de administración "bendita"; de hecho se escribió como una aplicación LUA. Por lo tanto, recibió un token restringido, y así lo hizo el malware como resultado. Este es el punto entero de privilegios mínimos. Si pierdes el control del sistema (quizás porque has ejecutado accidentalmente algún software malvado, o quizás porque acabas de hacer clic en el elemento de menú incorrecto), el daño se restringirá o quizás se evitará por completo.

Algunos administradores conscientes de la seguridad ya implementan esta directiva hoy en día. Soy uno de ellos. Tengo dos cuentas, una normal y otra administrativa. Inicio de sesión como usuario normal y, en ocasiones, cambio a mi cuenta administrativa cuando necesito administrar mi sistema de alguna manera, por ejemplo, para agregar un directorio virtual en mi máquina, crear una base de datos en Microsoft SQL™ Server, etc. (En caso de que se pregunte, acabe gastando aproximadamente el 95 por ciento de mi tiempo en ejecución como usuario normal, incluso al desarrollar software). El equipo de Longhorn ha formalizado este enfoque, una idea que a menudo se denomina "privilegio correcto en el momento adecuado" en la característica Administrador protegido (PA para abreviar). Esto significa que puedo ejecutarme como administrador todo el tiempo, pero seguir ejecutándose con privilegios mínimos. Ya no hay más cambios hacia atrás y hacia adelante, haciendo malabares con dos perfiles de usuario, etc.

Si esto suena como una idea clara y quiere ayudar a hacer posible que las personas realmente usen esta característica, entonces tendrá que ponerse en serio sobre la escritura de aplicaciones que se ejecutan con privilegios mínimos. Dado que si esta característica está habilitada, una aplicación que requiere más privilegios de lo que realmente necesita se interrumpirá innecesariamente incluso si un administrador lo ejecuta, a menos que se haya designado como una aplicación de administrador de confianza. Por supuesto, AIM podría venir a su rescate, pero no debe confiar en él, ya que Microsoft estima que el 20 % de las aplicaciones probablemente no podrá ser compatible con LUA a través de AIM. Si no se encuentra en este 20 por ciento, la aplicación no se ejecutará. Si esto sucede lo suficiente, nadie usará la característica de Administración protegido, y eso sería una cosa muy triste de hecho.

Otras ventajas surgirán a medida que se escriben más aplicaciones que se ejecutan con privilegios mínimos. Por ejemplo, las corporaciones finalmente podrán bloquear sus estaciones de trabajo, lo que permite a los empleados ejecutarse con cuentas con privilegios mínimos. Esto simplificará significativamente la administración y reducirá los costos. Ahora más que nunca es importante escribir aplicaciones que se ejecuten con privilegios mínimos. Puede marcar una diferencia en esta plataforma.

Aplicaciones administradas en Longhorn

Uno de los mensajes de PDC 2003 fue que las aplicaciones administradas son el futuro. Al escribir código administrado, puede aprovechar las ventajas de la última revolución en la seguridad en la plataforma Windows: seguridad a través de la identidad de código. El sistema de seguridad basado en evidencia proporcionado por Common Language Runtime (CLR) y, a menudo denominado CAS, o seguridad de "acceso a código", permite a CLR aplicar restricciones adicionales en el código en función de dónde procede, quién lo firmó, etc. Esta dimensión agregada de seguridad abre nuevas vías para la distribución de software. Al ejecutar código en un espacio aislado seguro, los clientes ahora pueden ejecutar código descargado de un servidor central, lo que hace que las características "sin tocar" y "hacer clic una vez" en la implementación sea factible, lo que reduce aún más los costos de administración. ¿Y quién prefiere una aplicación de Windows real que se ejecuta en su máquina a una aplicación basada en explorador, si la implementación y los riesgos de seguridad eran similares?

En Longhorn, cada aplicación administrada puede indicar los permisos específicos que necesita para funcionar a través del manifiesto de aplicación. La lista de código 1 muestra un manifiesto de ejemplo generado al compilar un proyecto "Aplicación Longhorn" generado por el asistente predeterminado. Anote la sección TrustInfo y el conjunto de permisos expresados allí. Estos son los permisos que la aplicación necesita para ejecutarse.

Lista de códigos 1. Un manifiesto de aplicación

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" 
manifestVersion="1.0" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 
assembly.adaptive.xsd">
  <assemblyIdentity name="MyLonghornApp" version="1.0.0.0" 
processorArchitecture="x86" asmv2:culture="en-us" 
publicKeyToken="0000000000000000" />
  <entryPoint name="main" xmlns="urn:schemas-microsoft-com:asm.v2" 
dependencyName="MyLonhornApp">
    <commandLine file="MyLonghornApp.exe" parameters="" />
  </entryPoint>
  <description asmv2:iconFile="App.ico" />
  <TrustInfo xmlns="urn:schemas-microsoft-com:asm.v2" 
xmlns:temp="temporary">
    <Security>
      <ApplicationRequestMinimum>
        <PermissionSet class="System.Security.PermissionSet" 
version="1" ID="SeeDefinition">
          <IPermission 
class="System.Security.Permissions.FileDialogPermission" version="1" 
Unrestricted="true" />
          <IPermission class="System.Security.Permissions.IsolatedStorageFilePermission" 
version="1" Allowed="DomainIsolationByUser" UserQuota="5242880" />
          <IPermission 
class="System.Security.Permissions.SecurityPermission" version="1" 
Flags="Execution" />
          <IPermission class="System.Security.Permissions.UIPermission" 
version="1" Window="SafeTopLevelWindows" Clipboard="OwnClipboard" />
          <IPermission 
class="System.Drawing.Printing.PrintingPermission, System.Drawing, 
Version=1.2.3400.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
version="1" Level="SafePrinting" />
          <IPermission class="MSAvalon.Windows.AVTempUIPermission, 
PresentationFramework, Version=6.0.4030.0, Culture=neutral, 
PublicKeyToken=a29c01bbd4e39ac5" version="1" 
NewWindow="LaunchNewWindows" FullScreen="SafeFullScreen" />
        </PermissionSet>
        <DefaultAssemblyRequest PermissionSetReference="SeeDefinition" 
/>
      </ApplicationRequestMinimum>
    </Security>
  </TrustInfo>
  <dependency asmv2:name="MyLonghornApp">
    <dependentAssembly>
      <assemblyIdentity name="MyLonghornApp" version="0.0.0.0" 
processorArchitecture="x86" />
    </dependentAssembly>
    <asmv2:installFrom codebase="MyLonghornApp.exe" 
hash="28c18a303c7fb7e9fe43a32b456f0932f52125a9" hashalg="SHA1" 
size="110592" />
  </dependency>
</assembly>

Una aplicación administrada compatible con LUA siempre incluirá una sección similar a esta, y el administrador de confianza de Longhorn usará esta información para determinar si se permite que la aplicación se instale en el equipo. Si la aplicación está codificada cuidadosamente, es posible que pueda ejecutarse con privilegios tan bajos que el administrador de confianza pueda asignarle una puntuación de "ningún riesgo", y la aplicación se puede instalar inmediatamente y ejecutar sin intervención del usuario. Sin embargo, si la aplicación puntúa una clasificación de riesgo más peligrosa en función de los permisos que solicita, se le pedirá al usuario un cuadro de diálogo que describa los posibles peligros que supone la aplicación. A continuación, el usuario puede elegir si quiere permitir que la aplicación se instale y ejecute.

Indicar sus intenciones por adelantado en el manifiesto es una buena idea, ya que si no lo hace, el administrador de confianza solo puede asumir lo peor de la aplicación, y la clasificación de riesgo expresada al usuario parecerá más siniestra. Por lo tanto, es una buena idea expresar los permisos que necesita en el manifiesto. No omita este paso.

En un estudio mencionado en PDC 2003, Microsoft encontró que el 40 % de los usuarios siempre hace clic en "No" cuando se presentan diálogos de seguridad como advertencias de descarga de controles ActiveX. Es claro que si quiere distribuir el software a los usuarios a través de Internet, esperará una clasificación de riesgo de "ningún riesgo" del administrador de confianza en Longhorn, por lo que no se le pedirá al usuario antes de instalar y ejecutar la aplicación. Por lo tanto, es posible que se pregunte si hay un conjunto documentado de permisos que siempre se puntuará "sin riesgo". Resulta que hay una definición de este tipo y se conoce como el conjunto de permisos SEE.

Conjunto de permisos "Sin riesgo"

Es posible que haya oído esto al que se hace referencia en PDC 2003 como SEE (Entorno de ejecución seguro), pero la mayoría de las personas encuentran ese término bastante confuso, por lo que simplemente llamaré a este conjunto de permisos sin riesgo. Longhorn se enviará con un conjunto de permisos especial que siempre puntuará "sin riesgo" con el administrador de confianza predeterminado en Longhorn. Si escribe una aplicación cuyos requisitos de permisos se encuentran completamente dentro del conjunto de permisos sin riesgo, se puede instalar y ejecutar sin mostrar ninguna advertencia de confianza. El código al que se conceden permisos solo dentro de este conjunto (al menos como se define inicialmente por Microsoft) no debe ser capaz de dañar la máquina de forma intencionada o accidental.

Por lo tanto, si desea que la aplicación se instale y ejecute sin que se le pida al usuario un cuadro de diálogo que tenga miedo, querrá restringirse a las actividades permitidas por este conjunto de permisos. Debe saber que el equipo de Longhorn está considerando la posibilidad de configurar este conjunto de permisos por parte de los administradores, por lo que lo que lo que se considera "ningún riesgo" en un sitio podría ser diferente en otro. Pero para la gran mayoría de las instalaciones de Longhorn, el conjunto de permisos sin riesgo será el predeterminado que se distribuye con el sistema operativo.

¿Qué aspecto tiene? Echa otro vistazo al manifiesto en La lista de códigos 1. Anote el identificador dado al PermissionSet definido en la sección TrustInfo, "SeeDefinition".

Este es el aspecto del conjunto de permisos sin riesgo para la compilación de versión preliminar de PDC 2003: FileDialogPermission sin restricciones le permite leer o escribir archivos de la elección del usuario mediante las clases Estándar OpenFileDialog y SaveFileDialog , pero no se le permite obtener información sobre la estructura del sistema de archivos del usuario, incluido el nombre del archivo que eligió el usuario. IsolatedStoragePermission permite que un ensamblado lea y escriba hasta 5 megabytes de estado específico del usuario en el disco duro del usuario sin tener que pedirle un cuadro de diálogo de archivo. SecurityPermission permite que el código se ejecute en primer lugar. UiPermission te permite dibujar en la pantalla, pero solo en tus propias ventanas, y te concede acceso limitado al Portapapeles (no puedes leer su contenido mediante programación, pero el usuario puede pegar desde el Portapapeles en tus controles). PrintingPermission le permite imprimir, pero solo si lo hace a través del cuadro de diálogo de impresión. El código no puede iniciar trabajos de impresión de forma silenciosa sin que el usuario sepa que lo está haciendo. El permiso específico de "Avalon" permite al código crear ventanas de pantalla completa siempre que tengan un borde controlado por el sistema operativo (por lo que no se puede suplantar la pantalla de inicio de sesión, por ejemplo).

Tenga en cuenta que esta definición cambiará casi seguramente con el tiempo; incluso puede cambiar antes de que los longhorn beta se envíen. Así que toma mi descripción aquí con un grano de sal. Esperemos que este artículo le ayude a empezar a examinar algunas de las características con privilegios mínimos de .NET Framework, como el almacenamiento aislado y los cuadros de diálogo comunes, ya que la definición final del conjunto de permisos sin riesgo requerirá que use estas características para evitar un cuadro de diálogo de confianza.

Definir un conjunto de permisos sin riesgo no es una tarea trivial. El equipo de Longhorn sabe que si su definición es demasiado restrictiva, no se podrán usar suficientes aplicaciones. Pero si es demasiado permisivo, el malware lo usará definitivamente. Esperamos que el equipo pueda encontrar el punto dulce. La figura 1 es un diagrama que muestra el intervalo de privilegios para las aplicaciones longhorn, desde una aplicación de administrador bendita hasta las aplicaciones diseñadas para ejecutarse con el conjunto de permisos SEE.

Figura 1. Tipos de aplicaciones

Herramientas

La creación de aplicaciones con privilegios mínimos nunca ha sido trivial. Debe tener instrucciones y herramientas que le ayuden. Hemos visto algunos ejemplos de estas herramientas en PDC 2003, el primero de los cuales es Visual Studio® 2005 (denominado "Whidbey" en el período de tiempo de PDC 2003).

Este nuevo entorno de desarrollo proporciona una serie de características que ayudan a facilitar el destino de un entorno con privilegios mínimos. Por ejemplo, puede elegir un conjunto de permisos que quiera aplicar al depurar la aplicación. Un excelente lugar para empezar para las aplicaciones longhorn sería el conjunto de permisos SEE. En el caso de las aplicaciones existentes, lo más probable es establecer como destino el conjunto de permisos de Internet, que está bastante cerca de cómo se define el SEE hoy en día.

Una vez que empiece a depurar con permisos reducidos, tendrá la certeza de encontrarse con algunas securityExceptions inesperadas. En la figura 2 se muestra un ejemplo clásico en el que el desarrollador usa un cuadro de diálogo de archivo para solicitar al usuario un nombre de archivo y, a continuación, intenta leer el nombre de archivo proporcionado. Si se le concede FileDialogPermission (como está en el conjunto de permisos SEE), que le permite solicitar al usuario un archivo, pero específicamente no se le permite ver el nombre de archivo seleccionado por el usuario. En su lugar, debe llamar a un método (OpenFile) para abrir una secuencia que puede usar para leer desde el archivo. Visual Studio 2005 proporciona consejos para ayudar al desarrollador a encontrar la manera correcta de usar la clase OpenFileDialog para evitar la excepción de seguridad.

Ilustración 2. Mejor compatibilidad con herramientas

Otra herramienta útil que se anunció en PDC 2003 se denomina PermCalc. Se trata de una herramienta de línea de comandos que evalúa un ensamblado y determina mediante heurística los permisos que necesita para ejecutarse. Esta característica también está prevista para su inclusión en Visual Studio 2005. Esta es una excelente manera de dirigirse a entornos con privilegios mínimos. Una herramienta similar que existe hoy en día se denomina Comprobador de aplicaciones de Windows, parte del Kit de herramientas de compatibilidad de aplicaciones de Windows. Esta herramienta puede ayudarle a detectar cuándo la aplicación infringe reglas como escribir en partes protegidas del sistema de archivos o del registro.

Resumen

Longhorn promete ser una gran plataforma para aplicaciones con privilegios mínimos. Comience hoy escribiendo código administrado, en primer lugar. Al compilar aplicaciones de escritorio, consícelas como compatibles con LUA (y use el Comprobador de aplicaciones de Windows para ayudar a comprobar el trabajo). Si puede, dirigirse al conjunto de permisos de Internet por ahora, y es probable que se ajuste directamente a la SEE cuando longhorn se envíe.

Para obtener más información

Lea el libro de Brent Rector, Presentación de "Longhorn" para desarrolladores.

 

Acerca del autor

Keith Brown es un consultor independiente especializado en seguridad de aplicaciones. Creó el libro Programming Seguridad de Windows (Addison-Wesley, 2000) y está escribiendo un nuevo libro de seguridad para programadores de .NET. Lea el nuevo libro en línea en http://www.develop.com/kbrown.