LUKE PUPLETT

Following good practice and riddling your methods with tracing code could lead to your projects requiring the most dangerous (for want of a less sensationalist word) security permission: UnmanagedCode! (den, den, DERRR)

Last night I was using Permcalc to check the permissions on an assembly that I was preparing to ship. Before building the library for release, I needed to add the necessary declarations to rescind any permissions granted by the CLR that are surplus to requirements. How conscientious.

During the course of producing the Permcalc reports I noticed the following in the report:

<IPermission version="1" class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Flags="UnmanagedCode, ControlEvidence" /> 

I was pretty sure I’d not been calling any low-OS-level methods or parts of the Framework which do. Caveat: at some point, most of the Framework calls unmanaged code but it shields its consumers by way of having FullTrust by definition and using Assert to prevent demands looking at the caller permission set.

By adding –Stacks to the Permcalc command line, I then inspected all my methods looking for this severe security requirement, then checked their call stacks to determine if there were any calls being made that could be so demanding.

I followed the trail to an Instrumentation assembly I wrote years ago in my first months exploring .NET. I remember reading about how sprinkling tracing lines within one’s methods was a great idea and a good thing for programmers to do. So I did it.

The System.Diagnostics.Trace class MSDN documentation clearly states under the .NET Framework Security section:

SecurityPermission

for operating with unmanaged code. Security action: Demand. Associated enumeration: SecurityPermissionFlag..::.UnmanagedCode

Of course now it turns out that be doing this I have inadvertently bound all my dependant assemblies and projects to needing permission to execute unmanaged code, which of course in .NET land is a free pass to execute whatever some malicious logic pleases.

Because of the unexpectedly severe requirements of such an inert looking class I was roused to see if there were anymore .NET classes harbouring such devilish details.

I ran this into Bing

"for operating with unmanaged code" site:microsoft.com

But the motley assortment of Framework artefacts such as Marshal and various window handling methods made Trace all the more conspicuous and somewhat ironic.

I’m going to have to extricate myself of all that extraneous instrumentation. Ba! I’m even having difficulty saying it.