Programmatic Security (part 3) - Permission Attributes

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
1/11/2011 11:41:57 AM

3. Permission Attributes

All security permission classes have equivalent attribute classes. You can apply the security attributes instead of programmatically creating a permission class and demanding a stack walk or installing a stack-walk modifier. Using the permission attributes is called declarative security. All the attributes are used in a similar manner. Their constructor accepts an enum of type SecurityAction, indicating what security action to take:

    public enum SecurityAction

In addition, you need to set public properties of the attributes, instructing .NET what permission values to take upon the security action. Example 7 is similar to Example 2, except it uses declarative security to demand file I/O permission for a specific predetermined file before proceeding to perform the calculation.

Example 7. Declaratively demanding permission before performing an operation
class MyClass
[FileIOPermission(SecurityAction.Demand,Write = @"C:\Results.txt")]
public void Calclulate( )
//Perform calculation here and save results
DoWork( );
SaveResults( );
//Helper methods:
void DoWork( )
void SaveResults( )

In Example 7, .NET demands file I/O permission in every call to the method. If you need to repeat the same security actions in all the methods of a class, you can apply the security attribute on the class itself:

    [FileIOPermission(SecurityAction.Demand,Write = @"C:\Results.txt")]
class MyClass

The main difference between declarative security and programmatic security is evident when you compare Example 7 to Example 2. With programmatic security, the value of the permission (such as a filename, call time, parameter values, machine name, and so on) can be decided at runtime. With declarative security, the value is static and has to be known at compile time. In general, whenever the permission value is known at compile time, you should use declarative instead of programmatic security. Example 8 is functionally identical to Example 6, but it's much simpler because it uses declarative security.

Example 8. Declaratively asserting unmanaged code access permission and demanding UI permission
[SecurityPermission(SecurityAction.Assert,UnmanagedCode = true)]
Window = UIPermissionWindow.SafeSubWindows)]
public static void Show(string text,string caption)
HandleRef handle = new HandleRef(null,IntPtr.Zero);

You can also apply declarative security directly on the interop method, instead of the wrapper method.

When you apply a security attribute to the scope of a class, it affects all members of the class.

3.1. Choice actions

.NET 2.0 added the choice options to the SecurityAction enum, allowing you to combine permissions in a logical OR, instead of AND. Consider the following security demands on the method SomeMethod( ):

    [UIPermission(SecurityAction.Demand,Unrestricted = true)]
[FileIOPermission(SecurityAction.Demand,Unrestricted = true)]
void SomeMethod( )

Because SomeMethod( ) has two security permission demands on it, both permissions have to be granted for the method to be used. If you want instead to demand that either one of the permissions has to be granted, use the SecurityAction.DemandChoice value:

    [UIPermission(SecurityAction.DemandChoice,Unrestricted = true)]
[FileIOPermission(SecurityAction.DemandChoice,Unrestricted = true)]
void SomeMethod( )

Now at least one of the permissions has to be granted, but not necessarily both. This sort of demand is called a demand choice.

3.2. Link-time demands

Declarative security offers capabilities not available with programmatic security demands. You can request that the permission be demanded at link time, during JIT compilation, instead of at call time. Link-time demands are specified using the SecurityAction.LinkDemand value for the security action. For example:

Window = UIPermissionWindow.SafeTopLevelWindows)]
public void DisplaySomeUI( )

When the security action is set to the SecurityAction.LinkDemand value, .NET demands permission only of the caller immediately up the call chain linking to the method. Subsequent calls to the method aren't verified to have the permission. If the client doesn't have the demanded permission, a security exception is raised as early as possible—usually when the client first tries to link to the method, instead of at a later point in time. You can still demand the security permission on every call using programmatic security, but if you don't demand permission on every call, you eliminate the stack-walk penalty. The downside to this approach is that malicious clients can use a middleman component with the required permissions to link against the demanding component and then call the middleman, without being subjected to the stack walk. Use SecurityAction.LinkDemand without a per-call demand only if you know that the call chain leading to the object will remain static and is secure.

Link-time demands are especially useful in conjunction with the attribute StrongNameIdentityPermissionAttribute, defined as:

AttributeTargets.Method,AllowMultiple = true,Inherited = false)]
public sealed class StrongNameIdentityPermissionAttribute :
public StrongNameIdentityPermissionAttribute(SecurityAction action);
public string Name{get;set;}
public string PublicKey{get;set;}
public string Version { get; set; }

This attribute lets you insist that the assembly linking into your code is signed with a specified public key:
    public static class PublicKeys
public const string MyCompany = "1234567890...ABCDEF";
PublicKey = PublicKeys.MyCompany)]
public void MyMethod( )

You can apply the attribute StrongNameIdentityPermission on any user type. You can even insist on a particular version number and assembly name. The canonical use of StrongNameIdentityPermission is when you are forced to use a public class or a public method because of design considerations, so that you can call it from other assemblies you provide. Logically, however, these public types or methods are for your application's internal private use; you do not want other assemblies from other vendors to use your own application-internal types. In that case, all you need to do is demand your own public key so that no other party can use these public types or methods.

There is a pitfall associated with demanding StrongNameIdentityPermission: you cannot demand multiple keys, because an assembly can have only a single strong name. If you have multiple vendors to whom you want to allow access, use the LinkDemandChoice value instead:

PublicKey = PublicKeys.Vendor1)]
PublicKey = PublicKeys.Vendor2)]
public void MyMethod( )

: Identity Permissions

StrongNameIdentityPermission is a special type of permission called an identity permission. Identity permissions allow code to demand that its callers have a particular identity. The PublisherIdentityPermission permission demands that the caller is signed with a particular certificate. The UrlIdentityPermission, SiteIdentityPermission, and ZoneIdentityPermission permissions demand that the calling assemblies originate from a specific URL, site, or zone, respectively. The GacIdentityPermission permission allows you to demand that the calling assemblies are installed in the GAC. You can demand (or assert) identity permissions programmatically, just like any other permission, or you can apply them declaratively using a matching set of attribute classes.

To use StrongNameIdentityPermissionAttribute, you need a string representing a public key. You can use the .NET Configuration tool to extract the public key from an assembly by constructing a code group that uses the Strong Name evidence and simply copying and pasting the value from the "Public key" text box. Another solution is to use the sn.exe command-line utility. The -e switch extracts the public key from an assembly, and the -tp switch converts the key to a string representation.

3.3. Inheritance demand

A malicious party can derive from a class, override demanding methods, and then provide its own implementation that does not demand the permission, yet uses much of the functionality at the base-class level. In addition, the subclass can use protected members and helper methods for its own purposes. Component library vendors can use declarative security to prevent malicious parties from abusing their components via inheritance. The component vendor can apply the required security permissions using the SecurityAction.InheritanceDemand value, indicating to .NET to demand the permission of the subclasses. For example, here's how the BaseClass class can demand that its subclasses have been granted unrestricted access to the filesystem:

public class BaseClass

When an inheritance demand is applied to a method, it verifies that the overriding subclass has the requested permission. Inheritance demand takes place during load time, and no stack walks are involved.

Neither programmatic nor declarative security can protect against untrusted code accessing public fields, because no stack calls are involved. Never provide public fields, and always use properties.

As with link-time demand and regular demands, SecurityAction also provides the InheritanceDemandChoice value. InheritanceDemandChoice allows you to specify a number of permission attributes and demand that subclasses be granted at least one of them.

: The WebBrowser Control and Code-Access Security

When using the WebBrowser control it is not enough to have WebBrowser permission, because the control demands also the safe top level windows permission (a part of UserInterface permission). This is because the WebBrowser control can cause new windows to be popped up. In addition, the WebBrowser control also demands the following: a link-time demand and inheritance demand for FullTrust, and a FullTrust demand on its constructor:

public class WebBrowser : WebBrowserBase
public WebBrowser();
//Rest of the members

This renders the control mostly useless for partially trusted clients, because such clients tend to link against the control directly, create it and use it, and thus require FullTrust themselves. The inclusion of the WebBrowser permission in the LocalIntranet, Internet and Everything named permission set is therefore mostly of little use if at all.

Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Video Sports
programming4us programming4us