The. NET runtime was designed to block the vulnerability of malicious code penetration and execution on remote machines, but some distributed systems always need to download and execute code from remote machines. If the CLR cannot fully trust an assembly, it will limit the actions that can be operated on it. This mechanism is called code access security (CAS). On the other hand, CLR implements a role-based security mechanism in which code execution depends on specific user accounts and permissions.
. Net is a managed environment that ensures security to a certain extent ,. most of the types in the Net Framework class library are fully trusted during installation.. Net Configuration Policy). These types are security-verified, which means that CLR checks Il and ensures that they do not perform any potentially dangerous operations, they do not require any special security licenses to access local resources. We should try to follow the same policy when writing code. If our Code does not require any special security license, we should avoid using any cas api to judge access permission, this will only reduce the code performance.
We need to use CAS APIs to access some protective resources that require special permissions. The most common protective resources are unmanaged memory and file systems, other protective resources include the database, network port number, Windows registry, and print subsystem. In each case, an exception occurs when code that does not have proper permissions is called to attempt to access these resources. In addition, accessing these resources may result in a security traversal of the stack during the runtime, so as to ensure that all the Assemblies have the appropriate permissions on the current call stack.
We can avoid unmanaged memory access by creating verifiable and secure assembly. The security plan that Xu machine refers to is that the concentration does not have any pointer to access the managed or unmanaged heap.
There are very few reasons to use non-secure code, and the most common reason is performance. When creating Insecure code blocks, consider separating these algorithms into a separate assembly, which limits the impact of Insecure code on our entire application. If the separation is implemented, only callers who need specific functions will be affected. We can still use other security functions in environments with stricter security restrictions.
The recommended memory access is very simple. Try to avoid access to the unmanaged memory.
For file systems,. net uses isolated storage to solve this problem. Isolated storage can be seen as a virtual directory based on the Assembly, application domain, and the current user. Some trusted assemblies can access the corresponding gr bucket, but cannot access other parts of the file system. Other assemblies and users cannot see their own isolated storage directories.
We can use isolated storage to persistently process data elements of a certain size, allowing some trusted code to save and load information from a specially divided location on the local disk .. . Net Environment defines the size limit for isolated storage for each application, which can place malicious code to overuse disk space to avoid putting the system in an unusable state.
For other protected resources that need to be accessed, when accessing these resources, our program needs to be completely trusted. Otherwise, we can only choose to completely avoid access to these resources.
. Net security model means that the program's behavior will match the permissions it has. We need to pay attention to the permissions required by the program and minimize them as much as possible. We should avoid requiring permissions that are not required by the program. The less protected resources the Assembly requires, the less chance it will generate security exceptions. We should try our best to avoid using resources that require security licenses. When some algorithms really require higher security licenses, we should isolate those codes in a separate set of programs.