Sorta', Kinda' Trusting Code

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.

ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon