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 Method	Permissions
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.
InkRenderer	UIPermissionWindow.SafeTopLevelWindows
Draw, DrawStroke	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.