Tool for limiting the permissions of .Net assemblies
I present to the community a simple but useful tool for managing access permissions to the .Net code of assemblies - Managed Sandbox. I advise you to pay attention to the utility NOT only to developers, but also to everyone who periodically uses .Net programs from untrusted sources (with a few caveats, but more on that below).
The article consists of 2 parts: (1) a bit of philosophy about the .Net platform security system, (2) a description of the Managed Sandbox utility and the reasons why it was necessary to create it.
Part 1. A bit of philosophy. Why doesn’t anyone take advantage of managed code to restrict execution rights for security?
The question is quite interesting. The very idea of managed code is to sacrifice execution speed, download speed, and memory in order to have full control over the code. Full control implies that we know exactly what the code will do and we can prohibit certain actions from it. In practice, this “controllability” is used only for system purposes: separation of contexts within one process, for managing the garbage collection process, etc.
And the most important thing for ordinary users is to know how it can harm the program that I just downloaded on the Web and prevent certain actions - there are no tools here, even few people know about such possibilities of .Net programs.
There are several reasons why a similar situation has developed in the .Net world:
1. 90% .Net programs require unlimited authority (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. Because there are no convenient tools for controlling access to the code (so that simple users can use these tools) - no one really thought about creating assemblies that can work with limited rights. By the way, in .Net 2.0, by default, signed libraries could not be called without FullTrust (in .Net 4.0 fixed).
By the way, running code with limited privileges is actively used in ClickOnce. But then again - the user does not know what the program can do, only the programmer knows this, who set restrictions on creating the distribution kit.
Part 2. Why create the Managed Sandbox utility if there is a standard .Net Configuration utility from MS that allows restricting code authority? What is the difference between the programs?
The main reason is that the .Net Configuration utility from MS is not very (or rather, very NOT) convenient to use (I’ll better keep silent about caspol):
1. To start the assembly with limited privileges, you first need to create a new code group, and then determine the permissions for this group. After using the program, these settings must be deleted so as not to clog the configuration file.
2. .Net Configuration is attached 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 authority (19 available, 30 in total). The rest, apparently, need to be set manually in the XML file.
4. To everything else, 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 permissions. Perhaps, any advanced user can handle this. Technically, to limit privileges, a separate application domain is used with the appropriate execution rights, the configuration file does not change.
Managed Sandbox is under development, many powers are not yet possible to detail. If anyone wants to take part in the development - you are welcome.
Download program: managedsandbox.codeplex.com/releases/view/51827
Download source: managedsandbox.codeplex.com/SourceControl/list/changesets
The article consists of 2 parts: (1) a bit of philosophy about the .Net platform security system, (2) a description of the Managed Sandbox utility and the reasons why it was necessary to create it.
Part 1. A bit of philosophy. Why doesn’t anyone take advantage of managed code to restrict execution rights for security?
The question is quite interesting. The very idea of managed code is to sacrifice execution speed, download speed, and memory in order to have full control over the code. Full control implies that we know exactly what the code will do and we can prohibit certain actions from it. In practice, this “controllability” is used only for system purposes: separation of contexts within one process, for managing the garbage collection process, etc.
And the most important thing for ordinary users is to know how it can harm the program that I just downloaded on the Web and prevent certain actions - there are no tools here, even few people know about such possibilities of .Net programs.
There are several reasons why a similar situation has developed in the .Net world:
1. 90% .Net programs require unlimited authority (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. Because there are no convenient tools for controlling access to the code (so that simple users can use these tools) - no one really thought about creating assemblies that can work with limited rights. By the way, in .Net 2.0, by default, signed libraries could not be called without FullTrust (in .Net 4.0 fixed).
By the way, running code with limited privileges is actively used in ClickOnce. But then again - the user does not know what the program can do, only the programmer knows this, who set restrictions on creating the distribution kit.
Part 2. Why create the Managed Sandbox utility if there is a standard .Net Configuration utility from MS that allows restricting code authority? What is the difference between the programs?
The main reason is that the .Net Configuration utility from MS is not very (or rather, very NOT) convenient to use (I’ll better keep silent about caspol):
1. To start the assembly with limited privileges, you first need to create a new code group, and then determine the permissions for this group. After using the program, these settings must be deleted so as not to clog the configuration file.
2. .Net Configuration is attached 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 authority (19 available, 30 in total). The rest, apparently, need to be set manually in the XML file.
4. To everything else, 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 permissions. Perhaps, any advanced user can handle this. Technically, to limit privileges, a separate application domain is used with the appropriate execution rights, the configuration file does not change.
Managed Sandbox is under development, many powers are not yet possible to detail. If anyone wants to take part in the development - you are welcome.
Download program: managedsandbox.codeplex.com/releases/view/51827
Download source: managedsandbox.codeplex.com/SourceControl/list/changesets