Sorta', Kinda' Trusting Code

By Don Kiely, ITworld |  How-to

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]).

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

ITworld Answers helps you solve problems and share expertise. Ask a question or take a crack at answering the new questions below.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question
randomness