Export (0) Print
Expand All

Security and Trust

The .NET Framework has a security model that treats applications differently depending on their origin. Executables and assemblies that are from a user's machine generally run with full trust; the same executables and assemblies run over the Internet generally run with partial trust. This is to prevent malicious code from either reading or modifying information it should not have access to, such as local files, items in the Clipboard, and other resources. If an executable calls an assembly, which in turn calls another assembly that requires a certain level of trust, then the lowest level of trust of all the components in the chain is applied. However, an administrator on a machine can set specific permissions that override the default permissions.

An overview of the security model is given in Secure, Light-Weight Client-Side Controls, and you can obtain more depth about the security model in Code Access Security in Practice. A good overview on the security of libraries (which is especially important for UserControl objects on a Web page) can be found in Using Libraries from Partially Trusted Code, and other security information on managed controls can be found in Writing Secure Managed Controls.

Permissions

Most managed objects and members in the Tablet PC Technologies API have two requirements:

  • Execution is always required.
  • FullTrust is required when the InheritanceDemand security action takes place. This means that full trust is required when a derived class inherits a class or overrides a method from the Tablet PC SDK.

The following table lists the classes and members that require additional permissions. The permissions for a given class also apply to all of its members not listed in this table.

Class or MethodPermissions
CanPaste

UIPermissionClipboard.AllClipboard

Ink.ClipboardCopy

UIPermissionClipboard.OwnClipboard

Ink.ClipboardPaste

UIPermissionClipboard.AllClipboard

InkCollector

UIPermissionWindow.SafeTopLevelWindows

InkCollector(IntPtr)

UIPermissionWindow.SafeTopLevelWindows and SecurityPermissionFlag.UnmanagedCode

InkCollector.Handle

UIPermissionWindow.AllWindows and SecurityPermissionFlag.UnmanagedCode (see note below)

InkEdit

UIPermissionWindow.SafeTopLevelWindows

InkOverlay

UIPermissionWindow.SafeTopLevelWindows

InkOverlay(IntPtr)

UIPermissionWindow.SafeTopLevelWindows and SecurityPermissionFlag.UnmanagedCode

InkOverlay.Handle

UIPermissionWindow.AllWindows and SecurityPermissionFlag.UnmanagedCode (see note below)

InkPicture

UIPermissionWindow.SafeTopLevelWindows

PenInputPanel

See note below.

Renderer

UIPermissionWindow.SafeTopLevelWindows

Renderer.Draw

UIPermissionWindow.SafeTopLevelWindows and SecurityPermissionFlag.UnmanagedCode

Renderer.Draw(IntPtr,Strokes), Renderer.Draw(IntPtr,Stroke)

UIPermissionWindow.SafeTopLevelWindows and SecurityPermissionFlag.UnmanagedCode

Renderer.InkSpaceToPixel(IntPtr,Point), Renderer.InkSpaceToPixel(IntPtr,Point[])

UIPermissionWindow.SafeTopLevelWindows and SecurityPermissionFlag.UnmanagedCode

Renderer.PixelToInkSpace(IntPtr,Point), Renderer.PixelToInkSpace(IntPtr,Point[])

UIPermissionWindow.SafeTopLevelWindows and SecurityPermissionFlag.UnmanagedCode

DynamicRenderer

UIPermissionWindow.SafeTopLevelWindows

DynamicRenderer(IntPtr)

UIPermissionWindow.SafeTopLevelWindows and SecurityPermissionFlag.UnmanagedCode

RealTimeStylus

UIPermissionWindow.SafeTopLevelWindows

RealTimeStylus(IntPtr), RealTimeStylus(IntPtr,Boolean), RealTimeStylus(IntPtr,Tablet)

UIPermissionWindow.AllWindows and SecurityPermissionFlag.UnmanagedCode

 

Note  It is generally preferable to use a control rather than a handle (IntPtr) for constructors, because controls require fewer permissions. Similarly, it is preferable to use a Graphics object rather than a handle for Renderer.Draw, Renderer.InkSpaceToPixel and Renderer.PixelToInkSpace.

Note  The InkCollector.Handle and InkOverlay.Handle properties do not require SecurityPermissionFlag.UnmanagedCode permission if the handle is for a Windows Forms control, but they do for other windows.

Note  For the PenInputPanel class, the following methods and properties require SecurityPermissionFlag.AllFlags: PenInputPanel(IntPtr), AttachedEditWindow, Busy, CommitPendingInput, CurrentPanel, DefaultPanel, EnableTsf, Factoid, Height, HorizontalOffset, InputFailed, Left, MoveTo, PanelChanged, PanelMoving, Refresh, Top, VerticalOffset, Visible, VisibleChanged, and Width.

Other Considerations

Some other known security considerations are:

  • Microsoft Internet Explorer 6 or higher is required in order for Web controls to work properly. With Internet Explorer 5.5, only initial managed controls load; you cannot load additional controls dynamically at run-time.
  • If you are using Windows XP Service Pack 2 (SP2) and CLR1.0, then having Web controls in Internet Explorer require adding the site as a trusted site, even if they are in the Intranet zone. However, when you do so, they will no longer run in the Trusted Site zone, although they do run in the Intranet zone. This issue is fixed with CLR1.1.

 

 

Send comments about this topic to Microsoft

Build date: 3/6/2012

Community Additions

ADD
Show:
© 2014 Microsoft