430 likes | 604 Vues
System.Security.Policy namespace. Chinmay Lokesh .NET Security CS 795 Summer 2010. Concepts Covered. Security Policy Introduction Policy Level – Code groups, Named Permission Sets, Fully Trusted Assemblies Policy Resolution Configuring Security Policy System.Security.Policy namespace.
E N D
System.Security.Policy namespace Chinmay Lokesh .NET Security CS 795 Summer 2010
Concepts Covered • Security Policy Introduction • Policy Level – Code groups, Named Permission Sets, Fully Trusted Assemblies • Policy Resolution • Configuring Security Policy • System.Security.Policy namespace
Introduction • How the runtime uses security policy to determine which permissions to grant an assembly or application domain based on its identity? • High-level explanation of security policy structure of security policy how the component elements interact at runtime • manipulate security policy programmatically – Topic of Concern
Security Policy : Intro • Security policy is the set of configurable rules that provide a mapping between evidence and permissions • Runtime uses security policy to determine which code-access permissions to grant an assembly or application domain based on the set of evidence that the assembly or application domain presents—a process known as policy resolution • Flexible and extensible • Confidently run managed code from any source
Policy Level (Continued) • Enterprise , machine and user levels are configurable by admin tools • Configure Application Domain programmatically • Runtime loads assembly and application domain and determines permission granted • In case of assembly the permissions granted by the application domain to which the assembly is loaded • Each policy level contains three key elements: Code groups, Named permission sets, Fully trusted assemblies
Code Groups (Continued) • code groups provide the mapping between evidence and permissions that the policy resolution process uses to determine which code-access permissions to grant an assembly or application domain • Each policy level consists of set of code groups organized into a tree structure • If the evidence meets the code group's membership condition, then the runtime grants the assembly or application domain the permissions contained in the code group's permission set.
Code Groups • Each code group has a name and a description and contains the following elements Membership Conditions
Code Groups Permission set • The permission set is the set of permissions to grant an assembly or application domain that qualifies for membership of the code group Child code groups • each policy level consists of a single tree of code groups with each code group having one or more child code groups • use of code group trees and simple membership conditions is a flexible model that allows you to create complex security policies
Code Groups Attributes • two optional attributes that you can assign to a code group in order to modify the normal policy resolution process Exclusive • The code group's permission set defines the maximum set of permissions that the assembly or application domain can get from the current policy level regardless of what other code groups it is a member of. LevelFinal • The runtime will not evaluate any policy level below the current level other than the application domain level
Named permission sets • Permission sets are simply groups of permissions to which you assign a name. Each policy level maintains its own set of named permission sets that are valid only within the scope of that policy level.
Fully trusted assemblies • each policy level contains a list of fully trusted assemblies. When the runtime loads any of these assemblies during policy resolution, it automatically assigns them full trust within that policy level; they are not subject to the normal policy resolution process • Why? • Under normal circumstances, as the runtime loads these assemblies, it would need to resolve the policy for each one to determine their permissions. However, if the policy resolution of these assemblies required the runtime to instantiate security classes contained within the same assemblies, the runtime would need to resolve the policy for the same assembly again, resulting in a never-ending policy resolution loop
Policy Resolution • I am talking only about Assemblies • When resolving policy for an assembly, the runtime starts at the enterprise policy's root code group and checks the assembly's evidence against the code group's embership condition. • The runtime then traverses the code group tree by comparing the assembly's evidence with each child code group of the current code group. At any stage, if the assembly does not qualify for membership of a code group, then the runtime does not grant the code group's permission set to the assembly, and policy resolution moves on to the next peer-level code group, ignoring the current code group's children.
Calculating Policy Level Permissions The runtime uses this process to determine the permissions granted by each policy level and then intersects them to calculate the final code-access permission set for the assembly
Configuring Security Policy • Using the .NET Framework Configuration tool (Mscorcfg.msc), a Microsoft Management Console (MMC) plug-in provided with the .NET Framework that provides a graphical interface with which to administer security policy • Using the Code Access Security Policy tool (Caspol.exe), a command-line tool provided with the .NET Framework • Programmatically, using the security classes contained in the .NET class library - Topic of Concern • Manually, by editing the XML contained in the individual security policy files
Programming Security Policy • To have complete control over all security policy features • How to program the key components of security policy, starting with code groups and membership conditions, then moving on to policy levels • Covering Code Groups and PolicyLevel
Programming Code Groups • The abstract system.Security.Policy.CodeGroup class provides the base representation of a code group and defines the functionality that lies at the heart of the policy resolution process • Four noninheritable subclasses • CodeGroup is a container for all of the elements discussed in previous slides
Programming Code Groups Membership condition • An object that implements the System.Security.Policy.IMembershipCondition interface provides the functionality to determine whether an assembly or application domain qualifies for membership to the code group, for eg – Zone= Internet Policy statement • The policy statement contains values that specify the effect the CodeGroup has on assemblies and application domains that are members of the group. The System.Security.Policy.PolicyStatement class represents a code group's policy statement
Code Groups Children Each CodeGroup contains an ordered list of child CodeGroup objects
Code Group Resolve • The most important method of the CodeGroup class is Resolve, which takes an Evidence collection as an argument, called at runtime • The key difference between each of the CodeGroup subclasses is how they process the Resolve method • In the Resolve method, the CodeGroup is responsible for determining if the assembly's evidence qualifies it for membership, how to apply any attributes, and how or if the CodeGroup should use its children to continue the policy resolution process.
Code Group Resolve UnionCodeGroup Members are tested against all child code groups for membership. The resulting PolicyStatement contains the union of the code group's permission set and the permission sets of each child of which the assembly is also a member FileCodeGroup FileCodeGroup does not support attributes and does not contain a statically defined permission set. With each call to Resolve, if the evidence of the assembly contains "file://"-based Url evidence, the FileCodeGroup dynamically generates a permission set that contains a System.Security.Permissions.FileIOPermission granting access to the directory specified in the Url evidence.
Code Group Resolve NetCodeGroup if the evidence of the assembly contains "http://" or "https://" Url (or Site) evidence, the NetCodeGroup dynamically generates a permission set FirstMatchCodeGroup This operates the same UnionCodeGroup but evaluates members against its children only until it finds the first matching child group.
Programming membership conditions • Membership conditions are classes that implement the IMembershipCondition interface • you can get and set the IMembershipCondition through the CodeGroup.MembershipCondition property after construction • # C# bool Check(Evidence evidence);
membership condition classes # C# // Create a membership condition to match all code. IMembershipCondition m1 = new AllMembershipCondition( ); // Create a membership condition to match all code with // Internet Zone evidence. IMembershipCondition m2 = new ZoneMembershipCondition(SecurityZone.Internet); // Create a membership condition to match all code from // all "oreilly.com" Sites. IMembershipCondition m3 = new SiteMembershipCondition("*.oreilly.com"); // Create a membership condition to match all code with // the same Publisher certificate as was used to sign // the SomeFile.exe assembly. IMembershipCondition m4 = new PublisherMembershipCondition( X509Certificate.CreateFromSignedFile("SomeFile.exe") );
Programming policy statements • Provide a PolicyStatement as an argument to the UnionCodeGroup and FirstMatchCodeGroup constructors, and you can get and set the PolicyStatement after construction through the CodeGroup.PolicyStatement property. • The FileCodeGroup and NetCodeGroup classes do not require you to set a policy statement, because they generate their permission sets dynamically and do not support attributes • The PolicyStatement class provides two constructors
PolicyStatementAttribute enumeration • The PolicyStatement class provides two constructors. The first takes a System.Security.PermissionSet argument specifying the permissions a code group grants to its members. The second constructor takes both a PermissionSet and a member of the System.Security.Policy.PolicyStatementAttribute enumeration
how to create PolicyStatement objects # C# // Create a PolicyStatement that grants Unrestricted access // to everything PolicyStatement p1 = new PolicyStatement( new PermissionSet(PermissionState.Unrestricted) ); // Create a PolicyStatement that grants read access to the // file "C:\File.txt" and specifies the LevelFinal attribute. PermissionSet pset = new PermissionSet( new FileIOPermission(FileIOPermissionAccess.Read,@"C:\File.txt")); PolicyStatement p2 = new PolicyStatement( pset, PolicyStatementAttribute.LevelFinal);
Creating code groups • UnionCodeGroup with the Exclusive attribute that matches all code downloaded from any web site in the oreilly.com domain and grants it unrestricted access to the filesystem C# // Create the permission set and add unrestricted file access. PermissionSet pset = new PermissionSet(PermissionState.None); pset.AddPermission(new FileIOPermission(PermissionState.Unrestricted)); // Create the policy statement and set the Exclusive attribute. PolicyStatement pstate = new PolicyStatement(pset, PolicyStatementAttribute.Exclusive); // Create the membership condition to match all "*.oreilly.com" sites. IMembershipCondition mcon = new SiteMembershipCondition("*.oreilly.com")
Programming Policy Levels • The .NET class library contains the System.Security.Policy.PolicyLevel class to represent all security policy levels: enterprise, machine, user, and application domain. • The PolicyLevel class is a container for the component elements we described in "Security Policy Levels": fully trusted assemblies, named permission sets, and code groups
Managing named permission sets //Create a new application domain policy level PolicyLevel p = PolicyLevel.CreateAppDomainLevel( ); // Get a copy of the default permission set named "Internet" and // call it "NewPermissionSet" NamedPermissionSet ps = p.GetNamedPermissionSet("Internet").Copy("NewPermissionSet"); // Add the new permission set p.AddNamedPermissionSet(ps); // Modify the permission set "NewPermissionSet" to grant unrestricted // access p.ChangeNamedPermissionSet("NewPermissionSet", new PermissionSet(PermissionState.Unrestricted)); // Remove the NewPermissionSet permission set p.RemoveNamedPermissionSet("NewPermissionSet");
Managing the code group tree • get and set the root code group of the policy level's code group tree using the RootCodeGroup property
Links • http://www.cs.odu.edu/~clokesh/tree.txt • http://msdn.microsoft.com/en-us/library/system.security.policy.aspx