This permission defines a collection of simple permission flags used by the security system.
Execution: This permission must be granted in order for code to run – not granting this permission gives administrators a mechanism to prevent certain code from running at all.
Assertion: Ability to override the security check for any permission that has been granted.
UnmanagedCode: Ability to call unmanaged code, such as calling native code via P/Invoke or via COM interop.
SkipVerification: Allows code to run without passing verification. This permission should only be granted to code that is trustworthy as it circumvents the normal verification process that protects against attacks by breaking the rules of containment based on memory type safety. Use of this permission is justified when code is known to be safe on the basis of trust or other inspection, or known-verified code may skip repeated verification for performance reasons. Since without verification strict security enforcement cannot be ensured by the system, this permission should only sparingly be used when absolutely necessary. As this permission effects verification only, user code check for this permission is not a useful operation.
SerializationFormatter: Represents the right for code to be a serialization formatter—giving code the ability to get and set any non-transient data members of serializable types. This permission allows code to discover and alter the private state of an instance. Code with this permission can access all the non-transient fields of any instance of a serializable type it gets a hold of regardless of its accessibility.
ControlDomainPolicy: This permission is required for a domain host to be able to specify domain-specific policy. See Policy specification for application domain policy.
Operation | Description | Security implications | Remarks |
---|---|---|---|
AppDomain.SetAppDomainPolicy | Ability to set application domain policy for an existing domain | Affects security policy and therefore permission grants |
ControlEvidence: Allows domain hosts to provide evidence to code loaded in domains created by the host. Typically evidence provided by the host in this manner would be location of origin or digital signatures found on the assembly. If a host does not have this permission than any domain it creates will have the same evidence as the host by default.
Operation | Description | Security implications | Remarks |
---|---|---|---|
AppDomain.CreateDomain( … Evidence …) | Ability to set host evidence upon domain creation | Escalation of Permission (by setting evidence that would increase the permission set of the loaded code) | Applies only when Evidence is passed to method |
AppDomain.Load( … Evidence …) | Ability to provide evidence upon loading an assembly into the domain | Escalation of Permission (by setting evidence that would increase the permission set of the loaded code) | Applies only when Evidence is passed to method |
ControlPolicy: Allows code to access and modify policy, both machine and user policy configuration.
Operation | Description | Security implications | Remarks |
---|---|---|---|
SecurityManager.SavePolicy | Ability to change security policy | Changes to policy will affect the permissions granted to code | |
SecurityManager.SecurityEnabled | Ability to turn off Runtime security enforcement | When security is turned off all code is, in effect, fully trusted |
ControlPrincipal: Allows code to replace the Principal object for a given thread. This function is important to applications using role-based security as the Principal object affects subsequent authorization actions based on identity/role information. For more information refer to the Role-based Security specification.
Operation | Description | Security implications | Remarks |
---|---|---|---|
AppDomain.SetPrincipalPolicy | Controls the type of Principal created | Allows code to change the behavior of role-based security | |
Thread.CurrentPrincipal | Ability to replace the Principal object for the current thread | Spoofing of user identity (code could replace current role-based user info) |
ControlThread: Allows the following operations on threads that need protection against unrestricted use.
Operation | Description | Security implications | Remarks |
---|---|---|---|
AppDomain.GetThreads | Returns an array of the threads in the application domain | Information not needed by code that should not be able to manipulate threads. | |
Thread.SetCurrentContext | Sets thread’s context | Allows context switching | |
Thread.SetAppDomain | Sets thread’s domain | Allows app domain switching | |
Thread.PushDomain | (similar to above) | (same as above) | |
Thread.PopDomain | (similar to above) | (same as above) | |
Thread.Suspend | Suspend execution | Interferes with execution | |
Thread.Resume | Resume execution | (same as above) | |
Thread.Interrupt | Interrupt a thread | Interferes with execution | Thread is able to protect self from |
Thread.Sleep | Puts a thread to sleep | (same as above) | (same as above) |
Thread.Stop | Stops a thread running | (same as above) | (same as above) |
Thread.SetPriority | Set thread priority level | Take cycles away from others | Could allow up to a maximum |
Thread.SetBackground | Set fore/background | Interferes with execution |