Tool for limiting permissions of .Net assemblies
I present the community with a simple but useful tool for managing permissions to access .Net assemblies code - Managed Sandbox. I advise you not to pay attention to the utility not only to developers, but also to all those who periodically use .Net programs from untrusted sources (with a few reservations, but more on that below).
The article consists of 2 parts: (1) a little philosophy about the security system .Net-platform, (2) a description of the Managed Sandbox utility and the reasons why it was necessary to create it.
')
Part 1. A little philosophy. Why no one uses the power of managed code to limit execution rights for security?
The question is quite interesting. The very idea of ​​managed code: sacrifice execution speed, load speed and memory in order to have complete control over the code. Full control implies that we know exactly what the code will do and we can prohibit certain actions for it. Practically, this “controllability” is used only for system purposes: separation of contexts within one process, for controlling the process of garbage collection, etc.
And the most important thing for ordinary users is to know what can harm a program that I just downloaded on the Net and prohibit certain actions from it - there are no tools here, even few people know about such features of .Net programs.
There are several reasons why a similar situation has developed in the .Net world:
1. 90% of .Net programs require unlimited powers (the so-called FullTrust). This is due to the fact that most programs use old unmanaged components and libraries. For example, if you use WebBrowserControl in your .Net application, your assembly will require unlimited permissions.
2. Since There are no convenient tools to control access to the code (so that ordinary users can use these tools) - no one has thought much about creating assemblies that can work with limited rights. By the way, in .Net 2.0 the default signed libraries could not be called without FullTrust (in .Net 4.0 they fixed it).
By the way, launching code with limited permissions is actively used in ClickOnce. But again - the user does not know what the program can do, only the programmer who has established restrictions when creating the distribution kit knows this.
Part 2. Why do I need to create the Managed Sandbox utility, if there is a standard .Net Configuration utility from MS that allows you to restrict code privileges? What is the difference between programs?
The main reason is that the .Net Configuration utility from MS is not very (more precisely very NOT) convenient to use (I’ll better keep silent about caspol):
1. To run an assembly with limited permissions, you first need to create a new code group, and only then define the permissions for this group. After using the program, these settings need to be deleted in order not to clutter up the configuration file.
2. .Net Configuration is bound to the .Net version of the platform (each version of the platform needs its own program).
3. .Net Configuration allows you to manage only part of the permissions (19 available, a total of 30). The rest, apparently, must be set manually in the XML file.
4. In addition, the utility is quite complicated: to use it, you need to know the basics of .Net security. It is intended for advanced programmers and admins, but not for ordinary users.
Managed Sandbox is much easier to use: you just need to select the assembly and specify the necessary execution authority. With this, perhaps, can handle any advanced user. Technically, a separate application domain with the corresponding execution rights is used to limit permissions, the configuration file is not changed.
Managed Sandbox is in development, many powers are not yet possible to detail. If someone wants to take part in the development - you are welcome.
Download program: managedsandbox.codeplex.com/releases/view/51827
Download source code: managedsandbox.codeplex.com/SourceControl/list/changesets
The article consists of 2 parts: (1) a little philosophy about the security system .Net-platform, (2) a description of the Managed Sandbox utility and the reasons why it was necessary to create it.
')
Part 1. A little philosophy. Why no one uses the power of managed code to limit execution rights for security?
The question is quite interesting. The very idea of ​​managed code: sacrifice execution speed, load speed and memory in order to have complete control over the code. Full control implies that we know exactly what the code will do and we can prohibit certain actions for it. Practically, this “controllability” is used only for system purposes: separation of contexts within one process, for controlling the process of garbage collection, etc.
And the most important thing for ordinary users is to know what can harm a program that I just downloaded on the Net and prohibit certain actions from it - there are no tools here, even few people know about such features of .Net programs.
There are several reasons why a similar situation has developed in the .Net world:
1. 90% of .Net programs require unlimited powers (the so-called FullTrust). This is due to the fact that most programs use old unmanaged components and libraries. For example, if you use WebBrowserControl in your .Net application, your assembly will require unlimited permissions.
2. Since There are no convenient tools to control access to the code (so that ordinary users can use these tools) - no one has thought much about creating assemblies that can work with limited rights. By the way, in .Net 2.0 the default signed libraries could not be called without FullTrust (in .Net 4.0 they fixed it).
By the way, launching code with limited permissions is actively used in ClickOnce. But again - the user does not know what the program can do, only the programmer who has established restrictions when creating the distribution kit knows this.
Part 2. Why do I need to create the Managed Sandbox utility, if there is a standard .Net Configuration utility from MS that allows you to restrict code privileges? What is the difference between programs?
The main reason is that the .Net Configuration utility from MS is not very (more precisely very NOT) convenient to use (I’ll better keep silent about caspol):
1. To run an assembly with limited permissions, you first need to create a new code group, and only then define the permissions for this group. After using the program, these settings need to be deleted in order not to clutter up the configuration file.
2. .Net Configuration is bound to the .Net version of the platform (each version of the platform needs its own program).
3. .Net Configuration allows you to manage only part of the permissions (19 available, a total of 30). The rest, apparently, must be set manually in the XML file.
4. In addition, the utility is quite complicated: to use it, you need to know the basics of .Net security. It is intended for advanced programmers and admins, but not for ordinary users.
Managed Sandbox is much easier to use: you just need to select the assembly and specify the necessary execution authority. With this, perhaps, can handle any advanced user. Technically, a separate application domain with the corresponding execution rights is used to limit permissions, the configuration file is not changed.
Managed Sandbox is in development, many powers are not yet possible to detail. If someone wants to take part in the development - you are welcome.
Download program: managedsandbox.codeplex.com/releases/view/51827
Download source code: managedsandbox.codeplex.com/SourceControl/list/changesets
Source: https://habr.com/ru/post/103542/
All Articles