3

I have a property Foo on a class Bar:

public int Foo
{
   get
   {
      return GetFoo();
   }
   set
   {
      SetFoo(value);
   }
}

Both GetFoo and SetFoo are decorated with:

[SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.UnmanagedCode)]

As a result, FxCop correctly complains that the Foo property (or rather its implicit getter and setter methods) doesn't have the same LinkDemand:

CA2122 : Microsoft.Security : 'Bar.Foo.get()' calls into 'Bar.GetFoo()' which has a LinkDemand. By making this call, 'Bar.GetFoo()' is indirectly exposed to user code. Review the following call stack that might expose a way to circumvent security protection:

However, when I tried to apply the same SecurityPermission attribute to the property to fix this warning, it turned out that properties are not a valid target for this attribute.

How do I fix this FxCop warning properly?


edit: to respond to Eric Lippert's comment "why on earth LinkDemand"?
  1. I wrote a function using Marshal.GetIUnknownForObject, which has LinkDemand for unmanaged code permission.
  2. I ran FxCop, which complained with CA2122
  3. I googled CA2122 looking for hints on what the error means and how to resolve it
  4. In the first first google hit I saw Micheal Fanning's advice to use LinkDemand to resolve the error

After reading your reaction which seems to question my sanity, I quickly guessed that Fanning's advice was not applicable in my case. I have now taken a look at the Demand vs. LinkDemand article and will try to use Demand instead.

JasonMArcher
  • 14,195
  • 22
  • 56
  • 52
Wim Coenen
  • 66,094
  • 13
  • 157
  • 251
  • 5
    Another good question to ask is "why on earth are you doing a link demand for unmanaged code permission?" This strikes me as an extremely dangerous thing to do. Can you describe why this isn't a full demand? – Eric Lippert Oct 06 '09 at 17:34
  • 1
    Re: your updates: The important thing to remember is that a link demand means "I will skip the expense of a full demand; in exchange for better performance, *my caller* is responsible for ensuring the safe use of this method". If you are the caller then *you* are now responsible for ensuring that no evildoer can misuse the underlying method via use of your code. You can choose to do that by passing the buck further, and requiring *your* caller to take responsibility, or you can issue a full demand, or you can find some other way to keep it safe. – Eric Lippert Oct 07 '09 at 17:11
  • +1 for the response to Eric's comment. "*Why a link demand? Cause FxCop told me to.*" – Ian Boyd Nov 28 '11 at 15:05

2 Answers2

6

You should be able to apply the attribute to the getter and setter directly, i.e.:

public int Foo
{
   [SecurityPermission(...)]
   get
   {
      return GetFoo();
   }

   [SecurityPermission(...)]
   set
   {
      SetFoo(value);
   }
}
Eric Rosenberger
  • 8,987
  • 1
  • 23
  • 24
0

just in reference you can decorate it using

[PermissionSetAttribute(SecurityAction.LinkDemand, Name="FullTrust")]

see page: what does this security warning mean (.Net Process class)?

Community
  • 1
  • 1
cpoDesign
  • 8,953
  • 13
  • 62
  • 106