The impact of different levels of security-transparent code on types in. NET (C #)

The test code tests a method and a class that defaults to the code type under all trust permissions and partial trust permissions.

By default, these are attributes that are not added to other security-transparent types.

The code type can be:

1. Transparent codes (Transparent code)
2. Key codes (Critical code)
3. Reliable key Code (safe-critical code)

Test these three items with issecuritytransparent,issecuritycritical and issecuritysafecritical in the type class and the MethodInfo class. Note that these properties are not inherited from their common base class MemberInfo, because some memberinfo such as properties are not identifiable. (But the property's get and set can, they belong to the method)

As for simulating partially trusted code, we then execute code in the application domain by creating an application domain that gives partial permissions.

To test the code framework:

Using System;

Using System.Reflection;

Using System.Security;

Using System.Security.Permissions;

Class Program

{

static void Main ()

{

Running in all trusted environments

Test ();

To create a partially trusted application domain

var d = Createsandbox ();

Running in a partially trusted environment

D.docallback (() =

{

Test ();

});

}

Test method

static void Test ()

{

if (AppDomain.CurrentDomain.IsFullyTrusted)

Console.WriteLine ("All Trusted Environment");

Else

Console.WriteLine ("Partially trusted Environment");

var method = Methodbase.getcurrentmethod ();

Judging method

Console.WriteLine ("Default Method-Transparent code: {0,-5} Key code: {1,-5} key reliable code: {2}",

Method. Issecuritytransparent,

Method. Issecuritycritical,

Method. issecuritysafecritical);

Judging type

Console.WriteLine ("Default type-transparent code: {0,-5} Key code: {1,-5} key reliable code: {2}\n",

Method. Declaringtype.issecuritytransparent,

Method. Declaringtype.issecuritycritical,

Method. declaringtype.issecuritysafecritical);

}

Create a partially trusted environment

Static AppDomain Createsandbox ()

{

Initializing an empty permission set

var pset = new PermissionSet (permissionstate.none);

Add Execution (execute) Security permission without this permission code does not execute

PSet. Addpermission (New SecurityPermission (securitypermissionflag.execution));

Add additional permissions

PSet. Addpermission (New FileIOPermission (permissionstate.unrestricted));

PSet. Addpermission (New UIPermission (permissionstate.unrestricted));

PSet. Addpermission (New ReflectionPermission (permissionstate.unrestricted));

Appdomainsetup.applicationbase must be set or the application domain cannot be created successfully

var adsetup = new AppDomainSetup ();

Adsetup.applicationbase = AppDomain.CurrentDomain.SetupInformation.ApplicationBase;

var domain = Appdomain.createdomain ("New AppDomain",

Null

Adsetup,

PSet);

return domain;

}

}

The result in Level 2 is this (after. NET 4.0 (including 4.0) the CLR defaults to using Level 2 types)

Operation Result:

All trusted Environments

Default method-Transparent code: False Key code: True key Reliable code: false

Default type-Transparent code: False Key code: True key Reliable code: false

Partially trusted environment

Default method-Transparent code: True Key code: false key Reliable code: false

Default type-transparent code: True Key code: false key Reliable code: false

As you can see, in Level 2, all trust environments, types and members are key codes. In the partial trust environment, they are all transparent code.

If you manually add SecurityTransparent or AllowPartiallyTrustedCallers to an assembly, the default is all transparent code:

Using System.Security;

[Assembly:securityrules (Securityruleset.level1)]

[Assembly:securitycritical]

. NET 4.0 +

[Assembly:allowpartiallytrustedcallers]

Or

[Assembly:securitytransparent]

Operation Result:

All trusted Environments

Default method-Transparent code: True Key code: false key Reliable code: false

Default type-transparent code: True Key code: false key Reliable code: false

Partially trusted environment

Default method-Transparent code: True Key code: false key Reliable code: false

Default type-transparent code: True Key code: false key Reliable code: false

Even with all trust environments, the default is transparent code.

In Level 1, you first have to use the Securityrules attribute to tune the CLR to run an assembly with a Level 1 policy.

Using System.Security;

[Assembly:securityrules (Securityruleset.level1)]

And then run the program, the result:

All trusted Environments

Default method-Transparent code: False Key code: True key Reliable code: TRUE

Default type-transparent code: True Key code: false key Reliable code: false

Partially trusted environment

Default method-Transparent code: True Key code: false key Reliable code: false

Default type-transparent code: True Key code: false key Reliable code: false

In a restricted environment, the same level 1 is considered transparent code. However, in a full trust environment, the type is treated as transparent code. However, the method (or other type member) is considered a critical reliable code (securitysafecritical), and because it is securitysafecritical it must also belong to SecurityCritical, so the critical code is also true.

So in Level 1, the Code for all trust environments can be accessed by default by partially trusted code, and if you do not want to do so, you can strongly name the entire assembly, and all public members of the strongly named assembly in Level 1 will have the implicit full permission of link Demand, The assembly for this partial trust environment is inaccessible. Of course, it is also possible to manually add link demand or all call stack traversal (full demand).

In Level 1, the SecurityTransparent attribute, like Level 2, makes all members of an entire assembly transparent. The AllowPartiallyTrustedCallers feature is not the same, it is mainly used in strong-named assembly to force the cancellation of the implicit link Demand. In this case, the assembly can also be accessed by partially trusted code. If you want to protect certain members, you can manually add the SecurityCritical feature or the displayed link Demand.

The SecurityCritical feature in Level 1 also has other uses:

Using System.Security;

[Assembly:securityrules (Securityruleset.level1)]

[Assembly:securitycritical]

If this is used, it is just like securitytransparent, except that you can manually add securitycritical to the member to specify that it is not a transparent code.

If you want the entire assembly to be all key code (at level 2, this is the default), the scope property using SecurityCritical is everything (deprecated in. NET 4.0, because. NET 4.0 is using level 2 by default):

Using System.Security;

[Assembly:securityrules (Securityruleset.level1)]

[Assembly:securitycritical (Securitycriticalscope.everything)]

Run the code again, all the members are the key code (only under the full permission, the partial permission is always transparent code)

All trusted Environments

Default method-Transparent code: False Key code: True key Reliable code: false

Default type-Transparent code: False Key code: True key Reliable code: false

The impact of different levels of security-transparent code on types in. NET (C #)