Link Demands and Wrappers
A special protection case with link demands has been strengthened in the security infrastructure, but it is still a source of possible weakness in your code.
If fully trusted code calls a property, event, or method protected by a LinkDemand, the call succeeds if the LinkDemand permission check for the caller is satisfied. Additionally, if the fully trusted code exposes a class that takes the name of a property and calls its get accessor using reflection, that call to the get accessor succeeds even though the user code does not have the right to access this property. This is because the LinkDemand checks only the immediate caller, which is the fully trusted code. In essence, the fully trusted code is making a privileged call on behalf of user code without making sure that the user code has the right to make that call.
To help prevent such security holes, the common language runtime extends the check into a full stack-walking demand on any indirect call to a method, constructor, property, or event protected by a LinkDemand. This protection incurs some performance costs and changes the semantics of the security check; the full stack-walk demand might fail where the faster, one-level check would have passed.
Note
In the .NET Framework version 4, partially trusted code has been redefined as transparent code. The transparency model draws a barrier between code that can do privileged things (critical code), such as calling native code, and code that cannot (transparent code). Transparency replaces the use of the LinkDemand for full trust to identify fully trusted code with the SecurityCriticalAttribute. For more information about this and other changes, see Security Changes in the .NET Framework 4.