Security in .NET Framework applications
Security in .NET Framework applications
It is evidently possible to perform any activity on a computer by logging in as the administrator. As a result, an unmanaged application running under Windows is granted full access rights for the user who is running it. There are no obstacles that could stop the administrator user’s operations in this scenario if he unintentionally executed a malicious file.
You should use a user with restricted access to the computer to log in in order to prevent this scenario. Code access security (CAS – Code Access Security), an operating mode that enables you to govern the rights that each application must possess, is a crucial idea in this context.
A security mechanism called CAS enables administrators and developers to manage application permissions in a manner similar to how user account permissions are managed. For instance, by using this system, it is possible to grant a programme the ability to read and write to the system registry. Most system resources’ permissions are under your control, including:
filing system
Register
Printers
event records
Since separate programmes cannot be handled and operated without any CAS constraints but only with limits connected to the privileges of the user utilised, the CAS may, unfortunately, only be used to apps based on the.NET Framework.
Any security system, including CAS, needs a mechanism to identify users and decide what they are capable of doing. This security system, however, cannot be based on usernames and passwords but rather on so-called proof since it identifies and grants permissions to apps rather than to users.
Information about a provided by the.NET Framework execution environment is evidence. Examples of this data include digital signatures or the website or folder from where a certain assembly is handled. Host evidence and assembly evidence are the two categories of evidence. The first gives data like the hash code or encrypted information about the assembly name, while the second provides data like the address or directory of the assembly.
The definition of a permission is the description of an access control. For instance, the File Dialog permission controls whether an assembly can offer Open or Save dialogues to a certain user, both, or neither. There are a number of default permissions in the.NET Framework, and it is also possible to define bespoke permissions. Among the ones that are predefined are:
Access to environmental variables is granted (such as Path, Username, Number-Of-Processors). You can select all environment variables or only a few to allow access to.
Active Directory access and management rights are granted by Directory Services.
Access to the event log is granted through the event log.
Limit access to files and folders using File IO. A list of paths to which an assembly is permitted access by way of read, write, etc. rights can be specified.
Printing: Limit the ability to print
Controls an assembly’s ability to obtain information about other assemblies.
Access restrictions for registry keys
Controls whether or not an assembly may access SQL Server is the SQL Client.
Determines whether or whether an assembly is capable of producing new windows is the user interface.
Determines whether an assembly has access to the internet and, if so, which websites.
Sets are groups of permissions ( permission sets ). Six permissions, for instance, are included in the set of Internet permissions: FileDialog, Isolated Storage, File, Security, User Interface, and Printing.
There are seven preconfigured permission sets in the.NET Framework:
An assembly is exempt from CAS permission verification while using fulltrust.
Enables an assembly to avoid permission checking is SkipVerification.
Nothing – Refuse to carry out a specific assembly
Internet – Gives an assembly a limited set of permissions.
Everything – Gives an assembly access to all features.
The idea of code groupings is essential. Similar to how user groups (user groups) are used to manage Windows accounts, these tools are used to assign each assembly’s unique set of permissions.
For instance, when an administrator wants to grant access to a particular folder, he first establishes a user group, then adds people to it, and finally grants the group permission.
With the exception of the fact that membership in a certain group is established by evidence (a concept we have encountered before), which is expressed as a criterion of belonging to the group, code groups function very similarly to other types of groups.
For instance, the Internet Zone code group should contain any code that runs online.
We can discuss security policies, which are logical groupings of code groups and sets of permissions, after describing the preceding notions. With the help of these tools, administrators can configure the CAS at various levels with great freedom. The four policy levels by default are enterprise, machine, user, and application domain.
The top level, called Enterprise, lets you control system-wide rules. Lower levels, called Machine and User, let you control policies that apply to the code that runs on certain machines. The minimum set of permissions permitted by each level is given to an assembly by the execution environment after each of these three levels has been evaluated independently.
To manage the rights of the individual assemblies, you must utilise the.NET Framework Configuration tool because the CAS is totally independent of operating system security. Operating system security is layered on top of CAS, and in practise, when deciding whether or not an assembly can carry out a particular activity, both types of security are examined and the most stringent set of permissions are used.
For instance, if the user executing the assembly does not have the necessary permissions yet the CAS grants the assembly write access to a particular folder, the assembly will not be able to write to that folder.
Here is a screenshot from the Microsoft website that nicely illustrates these ideas:
As a result, the.NET Framework Configuration tool offers a graphical interface for controlling security procedures and remote-access applications. We list a few of the different operations that can be done here:
examining an assembly to discover the code group to which it belongs
Putting an assembly through tests to see what rights it possesses
A new set of permissions being added
an additional code group
Levels of policy are reset
Let’s see how to perform the first of these procedures. We first launch the.NET Framework Configuration tool, then pick the Microsoft.NET Framework Configuration item on the Administrative Tools menu.
The next window appears
It requires that we first click on Evaluate Assembly and then Set Code Access Security Policy. Simply choose the path of the assembly you want to examine and click Next in the newly opened box. At this point, a window containing the important information’s summary will display.
By choosing the suitable things, the remaining processes can be completed in a manner that is remarkably comparable. As always, I encourage you to refer to the official Microsoft documentation to learn more about them.
