Solicitar permisos
Importante |
---|
En .NET Framework versión 4, se ha quitado la compatibilidad con el runtime para exigir las solicitudes de permisos RequestMinimum, RequestOptional y RequestRefuse.Este tema no se aplica al código basado en .NET Framework 4 o versiones posteriores.Para obtener más información sobre estos y otros cambios, vea Cambios de seguridad en .NET Framework 4. |
La solicitud de permisos es la manera que permite al motor en tiempo de ejecución saber lo que el código necesita poder hacer. Si desea solicitar permisos para un ensamblado, coloque atributos (sintaxis declarativa) en el ámbito del ensamblado del código. Cuando se crea el ensamblado, el compilador de lenguaje almacena los permisos solicitados en el manifiesto del ensamblado. En tiempo de carga, el motor en tiempo de ejecución examina las solicitudes de permiso y aplica reglas de directiva de seguridad para determinar qué permisos debe conceder al ensamblado. Las solicitudes solo influyen en el motor en tiempo de ejecución para rechazar permisos para el código, nunca para concederle más permisos de los que ya tiene. La directiva de administración local siempre tiene el control final de los permisos máximos que se conceden al código.
Nota |
---|
El código que está pensado para residir en un equipo se ejecuta en My_Computer_Zone que, de forma predeterminada, tiene plena confianza.La plena confianza hace que se aprueben todas las solicitudes de permisos.Las solicitudes de permisos siempre tienen éxito, incluso para los permisos de identidad donde no se cumple la condición de identidad.Si el código está pensado para ejecutarse solo en My_Computer_Zone, no tiene ningún sentido solicitar permisos.Si el código está pensado para ejecutarse en cualquiera de las demás zonas, se recomienda solicitar permisos. |
Nota |
---|
En .NET Framework 3.5 Service Pack 1 y posteriores, las aplicaciones de recursos compartidos de la intranet se ejecutan de forma predeterminada como de plena confianza.Si su aplicación está pensada para ejecutarse desde un recurso compartido, se ejecutará en modo de plena confianza al igual que una aplicación que resida en un equipo.Para obtener más información, vea Ejecutar aplicaciones de Intranet con plena confianza. |
Aunque el código no tenga que solicitar permisos para su ejecución en confianza parcial, hay razones importantes por las que el código siempre debe solicitar permisos:
Al solicitar permisos, aumenta la probabilidad de que el código se ejecute correctamente si se le permite que lo haga. El código que solicita un conjunto mínimo de permisos no se ejecutará, salvo que reciba esos permisos. Si no se identifica un conjunto de permisos mínimos, el código debe controlar discretamente cualquier situación y todas las situaciones en las que, si no se le hubiera concedido ningún permiso, no hubiera podido ejecutarse correctamente.
Solicitar permisos ayuda a garantizar que se conceden al código sólo los permisos que necesita. Si no se conceden permisos adicionales al código, no puede dañar los recursos protegidos por esos permisos adicionales, aunque sea atacado por código malintencionado o tenga errores que puedan aprovecharse para dañar los recursos. Deben solicitarse sólo aquellos permisos que el código necesita y ninguno más.
Solicitar permisos permite a los administradores conocer los permisos mínimos que necesita la aplicación de modo que puedan ajustar la directiva de seguridad en consecuencia. Puede determinar los permisos que su aplicación necesita en la pestaña Seguridad en la página de propiedades del proyecto para un proyecto de Visual Studio. Si un administrador no conoce esta información, la aplicación resulta difícil de administrar.
Al solicitar permisos, se informa al motor en tiempo de ejecución sobre qué permisos necesita la aplicación para funcionar o qué permisos específicos no necesita. Por ejemplo, si la aplicación escribe en el disco duro local sin utilizar el almacenamiento aislado, la aplicación deberá disponer de FileIOPermission. Si el código no solicita FileIOPermission y la configuración de seguridad local no permite que la aplicación tenga este permiso, se iniciará una excepción de seguridad cuando la aplicación intente escribir en el disco. Incluso si la aplicación puede controlar la excepción, no podrá escribir en el disco. Este comportamiento puede ser frustrante para los usuarios si la aplicación es un programa de edición de texto que han utilizado durante mucho tiempo. Por otra parte, si la aplicación solicita FileIOPermission y la configuración de seguridad local no permite que tenga FileIOPermission, la aplicación generará la excepción cuando se inicie y el usuario no tendrá que hacer frente al problema de pérdida de trabajo. Además, si la aplicación solicita FileIOPermission y se trata de una aplicación de confianza, el administrador puede ajustar la directiva de seguridad para permitir que se ejecute desde el recurso compartido remoto.
Si el código no tiene acceso a recursos protegidos ni realiza operaciones protegidas, no es necesario solicitar permisos. Por ejemplo, no es necesario realizar una solicitud de permisos si el código simplemente calcula un resultado basándose en las entradas que se le han pasado, sin utilizar ningún recurso. Si el código tiene acceso a recursos protegidos y no solicita los permisos necesarios, quizás aún pueda ejecutarse pero podría generar un error en algún momento de la ejecución si intentase obtener acceso a un recurso para el que no tiene el permiso necesario.
Para solicitar permisos, es necesario saber qué recursos y operaciones protegidos utiliza el código, y también qué permisos protegen esos recursos y esas operaciones. Además, se ha de realizar un seguimiento de los recursos a los que tienen acceso los métodos de bibliotecas de clases a los que llaman los componentes. Para obtener una lista de los permisos de acceso a código incluidos en .NET Framework, vea el tema Permisos.
En la tabla siguiente se describen los tipos de solicitudes de permiso.
Solicitud de permiso |
Descripción |
---|---|
Permisos mínimos (RequestMinimum) |
Permisos que debe tener el código para poder ejecutarse. |
Permisos opcionales (RequestOptional) |
Permisos que puede utilizar el código pero sin los cuales puede ejecutarse eficazmente. Esta solicitud rechaza implícitamente el resto de los permisos que no se hayan solicitado de forma específica. |
Permisos rechazados (RequestRefuse) |
Permisos que no desea que se concedan al código bajo ningún concepto, incluso si la directiva de seguridad permite que se le concedan. |
Realizar cualquiera de las solicitudes anteriores en conjuntos de permisos integrados (Solicitar conjuntos de permisos integrados). |
Conjuntos de permisos integrados, incluidos Nothing, Execution, FullTrust, Internet, LocalIntranet y SkipVerification. |
Realizar cualquiera de las solicitudes anteriores en conjuntos de permisos codificados en XML (Solicitar permisos codificados en XML). |
Representación XML (una cadena que contiene el conjunto de permisos codificados en XML o bien la ubicación de un archivo XML que contiene el conjunto de permisos codificados) de un conjunto de permisos que se desea. |
Si se especifican los permisos necesarios (mediante RequestMinimum), se concederá al código cada permiso solicitado que permita la directiva de seguridad. El código se podrá ejecutar sólo si se le han concedido todos los permisos que requiere.
Si se solicitan permisos opcionales sin solicitar también los permisos obligatorios, en algunos casos esto puede limitar seriamente los permisos concedidos a un ensamblado. Supongamos, por ejemplo, que la directiva de seguridad normalmente concede al Ensamblado A los permisos asociados al conjunto de permisos denominado Everything. Si el programador del Ensamblado A solicita el Permiso A como opcional y no solicita los permisos necesarios, se concederá al Ensamblado A el Permiso A (si lo permite la directiva de seguridad) o ningún permiso en absoluto.
Vea también
Tareas
Cómo: Solicitar permiso para un conjunto de permisos con nombre
Referencia
SecurityAction.RequestOptional
Conceptos
Seguridad de acceso del código
Conceptos básicos sobre la seguridad de acceso a código