Could performing a .NET "security check" lead to security errors?

Question

i have a snippet of code:

public void MyMethod()
{
   DirectoryEntry de; 
   ...
   de.AuthenticationType = AuthenticationTypes.Secure;
   ...
}

that FxCop chokes on:

CA2122: Do not indirectly expose methods with link demands

Resolution: MyMethod() calls into DirectoryEntry.AuthenticationType.set(AuthenticationTypes) which has a LinkDemand.
By making this call, DirectoryEntry.AuthenticationType.set(AuthenticationTypes) is indirectly exposed to user code.

Info: Do not wrap a method protected by a LinkDemand with a method that does not perform a security check. A LinkDemand checks the permissions of the immediate caller rather than checking the permissions of all callers in the call stack. In this case, the permissions of the wrapper method will be checked. If the wrapper method does not, itself, check the permissions of callers higher in the call stack, malicious code might be able to execute the wrapped function even though it lacks permission to do so."

i'm all for adding something, somewhere to "fix" this issue. But it can't add it if it will cause code that currently works for customers to spontaneously not work for customers.

Note: i don't know what to add, or where (FxCop doesn't include that information), and i don't want to delve too deep into the secret world of code security if it's a dead end.

If i add "a security check* to MyMethod, is there a possibility that code that currently works will stop working?

---

i assume that the code, as written now, will not work if someone doesn't have permission. In other words:

directoryEntry.AuthenticationType = AuthenticationTypes.Secure

will already fail if someone doesn't have correct "permissions". Adding a "security check" higher up in the call stack will not change that fact - only trigger the failure sooner. In that case adding the security check is OK.

On the other hand if:

public void MyMethod() {...}

MyMethod();

currently works, but

[SecurityCheck(...)]
public void MyMethod() {...}

AD.MyMethod()

will begin to fail, then i can't really add it.

Especially in library code that everyone uses.

---

The reason i can't test this for myself is that nobody knows how to replicate the situation where there would be a problem.

It's like when most people check credentials against active directory by trying to connect to AD with a username and password and read a property. You might not be allowed to read properties, even though the username/password is correct. i'd wager that nobody besides myself knows to to configure ActiveDirectory to replicate that failure case.

In my case, i presume nobody knows how to configure stuff so that the code security would fail.

Answer 1

i assume that the code, as written now, will not work if someone doesn't have permission

That's not true for a LinkDemand, which only requires the immediate caller to possess the target permission(s). This is the reason that FxCop is warning you of a potential problem: a malicious caller could potentially use your method to indirectly invoke a DirectoryEntry method despite not having sufficient CAS permissions to do so itself.

The best fix for this depends on several things, including which .NET Framework version you are using. For early .NET versions, add a LinkDemand or full demand for unrestricted DirectoryServicesPermission to your method. If FxCop is happy, you're pretty much done wrt this particular problem. However, it will be possible that some callers will no longer be able to invoke your method. If this is a problem, they you need to evaluate your use of DirectoryEntry and determine whether it could be abused by a malicious caller before you remove the protection.

For more recent .NET versions, things get more complicated. If you need help with this, please specify which version(s) of .NET you are targeting and whether you consider it necessary to support partially trusted callers.