Compartir a través de


Seguridad y confianza

.NET Framework tiene un modelo de seguridad que trata las aplicaciones de forma diferente en función de su origen. Los ejecutables y ensamblados que proceden de la máquina de un usuario suelen ejecutarse con plena confianza; los mismos ejecutables y ensamblados se ejecutan a través de Internet generalmente con confianza parcial. Esto es para evitar que el código malintencionado lea o modifique la información a la que no debe tener acceso, como archivos locales, elementos en el Portapapeles y otros recursos. Si un ejecutable llama a un ensamblado, que a su vez llama a otro ensamblado que requiere un determinado nivel de confianza, se aplica el nivel de confianza más bajo de todos los componentes de la cadena. Sin embargo, un administrador de una máquina puede establecer permisos específicos que invaliden los permisos predeterminados.

En Secure, Light-Weight Client-Side Controls, se proporciona información general sobre el modelo de seguridad en Seguridad de acceso a código en la práctica. Puede encontrar una buena introducción a la seguridad de las bibliotecas (que es especialmente importante para objetos UserControl en una página web) en Uso de bibliotecas de código de confianza parcialy se puede encontrar otra información de seguridad sobre los controles administrados en Escribir controles administrados seguros.

Permisos

La mayoría de los objetos administrados y miembros de la API tablet PC Technologies tienen dos requisitos:

  • La ejecución siempre es necesaria.
  • FullTrust es necesario cuando se realiza la acción de seguridad InheritanceDemand. Esto significa que se requiere plena confianza cuando una clase derivada hereda una clase o invalida un método del SDK de Pc tablet.

En la tabla siguiente se enumeran las clases y los miembros que requieren permisos adicionales. Los permisos de una clase determinada también se aplican a todos sus miembros que no aparecen en esta tabla.

Clase o método Permisos
canPaste UIPermissionClipboard.AllClipboard
ink.ClipboardCopy UIPermissionClipboard.OwnClipboard
Ink.ClipboardPaste UIPermissionClipboard.AllClipboard
InkCollector UIPermissionWindow.SafeTopLevelWindows
InkCollector(IntPtr) UIPermissionWindow.SafeTopLevelWindows y SecurityPermissionFlag.UnmanagedCode
InkCollector.Handle UIPermissionWindow.AllWindows y SecurityPermissionFlag.UnmanagedCode (consulte la nota siguiente)
InkEdit UIPermissionWindow.SafeTopLevelWindows
InkOverlay UIPermissionWindow.SafeTopLevelWindows
InkOverlay(IntPtr) UIPermissionWindow.SafeTopLevelWindows y SecurityPermissionFlag.UnmanagedCode
InkOverlay.Handle UIPermissionWindow.AllWindows y SecurityPermissionFlag.UnmanagedCode (consulte la nota siguiente)
inkPicture UIPermissionWindow.SafeTopLevelWindows
penInputPanel de Vea la nota siguiente.
InkRenderer UIPermissionWindow.SafeTopLevelWindows
draw, DrawStroke UIPermissionWindow.SafeTopLevelWindows y SecurityPermissionFlag.UnmanagedCode
Renderer.InkSpaceToPixel(IntPtr,Point), Renderer.InkSpaceToPixel(IntPtr,Point[]) UIPermissionWindow.SafeTopLevelWindows y SecurityPermissionFlag.UnmanagedCode
Renderer.PixelToInkSpace(IntPtr,Point), Renderer.PixelToInkSpace(IntPtr,Point[]) UIPermissionWindow.SafeTopLevelWindows y SecurityPermissionFlag.UnmanagedCode
DynamicRenderer UIPermissionWindow.SafeTopLevelWindows
DynamicRenderer(IntPtr) UIPermissionWindow.SafeTopLevelWindows y SecurityPermissionFlag.UnmanagedCode
RealTimeStylus UIPermissionWindow.SafeTopLevelWindows
RealTimeStylus(IntPtr), RealTimeStylus(IntPtr,Boolean), RealTimeStylus(IntPtr,Tablet) UIPermissionWindow.AllWindows y SecurityPermissionFlag.UnmanagedCode

 

Nota

Por lo general, es preferible usar un control en lugar de un identificador (IntPtr) para constructores, ya que los controles requieren menos permisos. Del mismo modo, es preferible usar un objeto Graphics en lugar de un identificador para Renderer.Draw, Renderer.InkSpaceToPixel y Renderer.PixelToInkSpace.

 

Nota

Las propiedades InkCollector.Handle y InkOverlay. Handle no requieren SecurityPermissionFlag.UnmanagedCode permiso si el identificador es para un control de Windows Forms, pero sí para otras ventanas.

 

 

Otras consideraciones

Algunas otras consideraciones de seguridad conocidas son:

  • Microsoft Internet Explorer 6 o superior es necesario para que los controles web funcionen correctamente. Con Internet Explorer 5.5, solo se cargan los controles administrados iniciales; No se pueden cargar controles adicionales dinámicamente en tiempo de ejecución.
  • Si usa Windows XP Service Pack 2 (SP2) y CLR1.0, tener controles web en Internet Explorer requiere agregar el sitio como sitio de confianza, incluso si están en la zona intranet. Sin embargo, al hacerlo, ya no se ejecutarán en la zona Sitio de confianza, aunque se ejecutan en la zona intranet. Este problema se ha corregido con CLR1.1.