Expected security exception from StrongNameIdentityPermissionAttribute is not produced by the CLR

Expected security exception from StrongNameIdentityPermissionAttribute is not produced by the CLR by James Hadwen

Closed

as By Design Help for as By Design

Type:	Bug
ID:	95767
Opened:	1/23/2005 5:08:58 PM
Access Restriction:	Public

Workaround(s)

view

User(s) can reproduce this bug

Declaration of the StrongNameIdentityPermissionAttribute should cause the validation of the strong name identity either during JIT or at the call (LinkDemand and Demand respectively). However the CLR is not performing this task.

I have a suspicion that this is related to bug FDBK18669, however the resolution of that bug report doesn't appear to fit with the findings below.

I've marked this as a 5, as the potential for security to be compromised through migration.

Thanks James

Details (expand)

English

Community Technology Preview December 2004

Security

Windows XP Professional

The following class shows an example paradox, the Assert statement should never evaluate to true

public class Class1
{
    [StrongNameIdentityPermission(SecurityAction.Demand, PublicKey = Keys.PUBLIC_KEY)]
    public Class1()
    {
        System.Diagnostics.Debug.Assert(Assembly.GetCallingAssembly().GetName().GetPublicKey().Length != 0);
    }
}

To test the paradox the code should be called from an unsigned assembly.

The assert does indeed evaluate to true if the object calling the code is unsigned, suggesting that StrongNameIdentityPermissionAttribute has had no effect.

Using 1.1 framework there is no Assert, (regardless of the related trust of assemblies). The Assert example above is just an example of a failure of StrongNameIdentityPermission with an unsigned class, however the scope of this bug is not limited to unsigned assemblies. Similar tests can be made using assemblies signed with "bad" keys, causing the same, unexpected result.

In the .NET Framework 2.0, all identity permission demands are satisfied by assemblies that have been granted full trust. There are two major reasons for this change:

1) Security: You're not getting any real security by doing link demands for identity permissions. Full trust code could load an assembly with specific strong name evidence, for example, and then that assembly could call something protected by a strong name identity permission demand. And of course full trust code could disassemble the assembly or otherwise hack into it to find out what's going on. There's no way to protect against a malicious full trust caller. So rather than continue a possible illusion of security, we changing the behavior. Please note that this doesn't apply to partially trusted callers. Identity permission demands are still evaluated for them.

2) Performance: We have to do lots of extra bookkeeping in full trust scenarios to keep track of identity permissions. This slows the performance of full trust scenarios, even when none of the code uses identity permissions. One of our primary goals is that full trust code has almost no perf drag from the security system. This feature is directly at odds with that, for little discernable benefit.

So if you're using identity permission link demands thinking they're protecting you from malicious full trust callers, that's not the case. However, if you're using identity permission link demands as a hygiene measure, to control how your components interact, you should look at some alternatives. The friend assemblies feature allows you to control access to internal members across assemblies. This is useful if you want to have semi-public APIs accessible across assemblies. For more general factoring scenarios, ideally you would have a mechanism that detects inappropriate calls at build time and allows you to fix them right away, rather than relying on runtime enforcement. You could accomplish this by annotating your assemblies with custom attributes, then using a custom FxCop rule to detect inappropriate cross-assembly calls. This would accomplish the hygiene goals with zero runtime overhead. We will consider more support for this in a future version of the runtime.

Thanks,
-Mike Downen, Common Language Runtime Security Team