Trusting .NET Code
- 24 September, 2002 09:40
Developing code with .NET is hard enough without worrying about security. This means that most developers take the easy way out and assume that their code will execute in a fully trusted environment. Full trust means that the user implicitly trust the code not to do anything nasty, and allows it full access to the resources on a machine or network. This includes giving it access to risky classes in the framework, such as those that read and write disk files, and-gasp!-unmanaged code.
From a developer's standpoint, assuming that code has full trust saves the tedious work of handling security exceptions every time they use an assembly from the framework or other source. Simple, and easier to meet insane deadlines imposed by clients and bosses.
But .NET also allows for partially trusted code, sometimes called semi-trusted in the .NET literature. With partially trusted code, the user can restrict what the code can do. For example, code that calculates some obscure statistical regression probably doesn't need to access any files on disk, assuming it already has the data it needs in memory. The user trusts it enough to let it run, but not enough to let it have free reign on all system resources. This is consistent with the security principle of giving code and users just the permissions they need to do their job, but no more. So a partially trusted application is restricted in some way by the framework.
The key to partially trusted code is the AllowPartiallyTrustedCallersAttribute in the System.Security namespace, commonly abbreviated APTCA. APTCA is an attribute used to mark assemblies, and does not take any arguments. The presences of this attribute serve to limit how attacks can be made through the code. Any managed code with a strong name is unusable by partially trusted code unless the code is marked with APTCA.
Here is where the work begins. If your application uses a strongly named assembly unmarked with APTCA, and partially trusted code calls your assembly, the call will fail if any downstream assembly is strongly named but does not have APTCA itself. This is all part of the security structure in .NET where all code must have a minimum level of access permissions before .NET will allow it to run. Assemblies in the .NET framework are no exception to this requirement, so you have to be sure that any system assemblies you use have the attribute as well. In the list of references below, I've included a line to an MSDN article that lists the System assemblies with APTCA.
Probably the only reliable way of determining whether a given assembly has APTCA set is to use the .NET framework SDK tool, ildasm.exe. Fire it up either from the command line or from the Start|Run menu in Windows, and load the assembly you're interested in (most system DLLs are located in C:\WINNT\Microsoft.NET\Framework\[framework version]). One you've loaded the assembly, double-click the MANIFEST item near the top of the treeview, and search through the manifest for APTCA.