0

I'm trying to understand FxCop CA2122 messages (probably before disabling the wretched things), and I have clearly overstepped my understanding of .NET CAS.

The application is a .EXE, not marked with AllowPartiallyTrustedCallers. We get CA2122 warnings from Code Analysis, complaining about our failure to propagate LinkDemands upwards from the lowest level of calls to methods which themselves have LinkDemands.

Obviously we can run around putting LinkDemands on callers, and then callers of callers, ad-infinitum. This seems entirely purposeless, as every invocation of this code is always going to be full-trust, and hence (AIUI) every link demand is always going to be met anyway. Eric Lippert seems to think it's highly dangerous to do that, too.

So:

  • What assembly-level attribute am I missing to say 'this code will only run at full-trust'? (I thought the absence of AllowPartiallyTrustedCallers' implied this, but perhaps not for .EXEs)

  • Or should I just turn off that CA warning and move on? I do like to understand them properly before I disable them...

Update: I was asked which framework version we're using - it's 2.0RTM, and it's extremely difficult to get upgraded past that point because it's on an XPe platform.

Will Dean
  • 39,055
  • 11
  • 90
  • 118

2 Answers2

2

Your underlying assumption that the assembly will only ever run as a fully trusted executable is faulty. There's nothing stopping someone who can get their hands on your assembly from using it as a referenced library assembly in a piece of malware. If you've altered a machine's CAS policy to grant full trust to your assembly regardless of how it's deployed, then the malware would potentially be able to use your assembly to execute operations for which it would otherwise not have had adequate permissions.

The upshot of this is that you really ought to be doing something to prevent satisfying link demands on the behalf of calling code, regardless of your intended deployment scenario. Given that you're targeting a full trust scenario yourself, this is actually going to be pretty easy. However, the exact approach depends largely on which version of the .NET Framework you're targeting, so could you please post that detail?

For .NET 2.0, the simplest approach to addressing the issue would be to apply either SecurityTransparentAttribute or SecurityCriticalAttribute to your assembly. Both attributes will result in the code in your assembly becoming security-transparent by default, which means that it cannot do things like satisfy link demands on behalf of its callers. If there are parts of your code that need to do things that are not allowed to security-transparent code, you should use the SecurityCriticalAttribute instead of SecurityTransparentAttribute at the assembly level since this will allow you to explicitly promote types and/or members to security-criticality if they need it. (For a bit more detail, see Link.)

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Nicole Calinoiu
  • 20,843
  • 2
  • 44
  • 49
1

If I'm understanding this correctly: http://msdn.microsoft.com/en-us/library/system.security.allowpartiallytrustedcallersattribute.aspx

The Link demand attributes tell .NET to enforce the full trust rule for the method. This also requires a strong name. While your app tree may be in a full trust environment, nothing is enforcing the rule for the public/protected methods and classes.

The AllowPartiallyTrustedCallers tells .NET you don't care who calls it.

Seems the security model changes in .NET 4.

  • So i guess the answer is yes, if you want to enforce it. But it's probably not worth the effort in a internal Corp. Environment. –  Nov 03 '10 at 20:45
  • Thanks for this - my (mis?)understanding was that if you add APTC then you need to be strong-named to allow it to take effect, but that NOT wanting to allow partial trust did not require strong-naming. – Will Dean Nov 04 '10 at 08:56