Security And Trust
Security And Trust |
This topic describes security and trust issues when deploying Tablet PC Web applications.
Introduction
The .NET framework has a security model that treats different 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 will generally run with partial trust. This is to prevent malicious code from either reading or modifying information it should not have access to (local files, what's in the clipboard, etc.). 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 .gif)
, and you can obtain more depth about the security model in Code Access Security in Practice . A good overview on the securities of libraries (which is especially important for System.Windows.Forms.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
When called under partial trust conditions, most managed objects and members in the Microsoft® Windows® XP Tablet PC Edition Software Development Kit (SDK) require two permissions:
- Execution .
- InheritanceDemand . This means that a derived class inheriting a class or overriding a method from the Tablet PC SDK is required to have been granted the specified permission.
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.
Note: It is always preferable to use a Control rather than a handle (IntPtr ) for constructors since they require fewer permissions. Similarly, it is preferable to use a Graphics object rather than a handle for Renderer.Draw, Renderer.InkSpaceToPixel and Renderer.PixelToInkSpace.
Other Issues
Some other known security issues are listed below:
- When running under partial trust, the mouse and painting events are not fired for the InkCollector and the InkOverlay. Instead, you can subscribe to events on the control that the InkCollector or InkOverlay is attached to. If you require making the distinction between the Painted and Painting events, you will need to use the RealTimeStylus rather than an ink collector.
- 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 Service Pack 2 (SP2) and CLR1.0, then having Web controls in Internet Explorer will 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 will run in the Intranet zone. This issue is fixed with CLR1.1.
- If you have an InkCollector or InkOverlay attached to a window or control, and you switch it to another window or control, then you will need to have UIPermissionWindow.AllWindows permission. If you are going to be building Web applications, it is preferable to keep your InkCollector or InkOverlay attached to a window until that window is going to be destroyed.