NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

SecurityPermission

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