Testing .NET code in partial trust environments

Question

I want to test the behavior of a certain piece of .NET code in partial trust environments. What's the fastest way to set this up? Feel free to assume that I (and other readers) are total CAS noobs.

@Nick: Thanks for the reply. Alas, the tool in question is explicitly for unmanaged code. I didn't say "managed" in my question, and should not have assumed that people would infer it from the ".NET" tag.

Answer 1

Use the Microsoft Application Verifier.

AppVerifier helps to determine:

• When the application is using APIs correctly: (Unsafe TerminateThread APIs., Correct use of Thread Local Storage (TLS) APIs., o Correct use of virtual space manipulations (for example, VirtualAlloc, MapViewOfFile).
• Whether the application is hiding access violations using structured exception handling.
• Whether the application is attempting to use invalid handles.
• Whether there are memory corruptions or issues in the heap.
• Whether the application runs out of memory under low resources.
• Whether the correct usage of critical sections is occurring.
• Whether an application running in an administrative environment will run well in an environment with less privilege.
• Whether there are potential problems when the application is running as a limited user.
• Whether there are uninitialized variables in future function calls in a thread's context.

Answer 2

Hi Curt,

This is an excellent question, especially from a TDD point of view and validating code under different trust scenarios.

I think the way I'd approach this would be something along the lines of -

• Create an AppDomain in my TDD code using the AppDomain.CreateDomain() overload that allows you to pass in a PermissionSet. The PermissionSet would be constructed to match the different trust scenarios you'd want to test against.

• Load the assembly containing logic under test into the app domain

• Create instances of types/call methods etc in app domain, trap security exceptions

Something kinda like that. I've not had time to knock up a proof of concept yet.

Kev

Answer 3

You should look at the .NET Framework Configuration Tool. It's in the .NET SDK, and you can find instructions on running it here... http://msdn.microsoft.com/en-us/library/2bc0cxhc.aspx

In the Runtime Security Policy section you'll find 3 policy levels: Enterprise, Machine and User. If you drill into Machine or User you'll find definitions of Code Groups and Permission Sets . When you say that you want to test some .NET code in partial trust environments, I guess you'll want to test against one of the standard permission sets already defined, such as Internet . You need to define a Code Group that matches your app (or specific assemblies) and assign your chosen permission set to that Code Group .

You can define your own custom Permission Sets too, but let's keep it simple for now.

Choose whether you want your new code group to exist at machine-wide scope, or just for your user account, and drill into the Machine or User policy level accordingly. You'll see a code group called All _ Code . Create a child code group inside that one, by right-clicking and selecting New...

Give it a name, say PartialTrustGroup , then click Next .

You have to specify a membership condition for this group, and there are various types. I like to create a specific folder called PartialTrust on my machine, and then create a URL membership condition that matches. So, my URL looks like this... file://c:/users/martin/documents/partialtrust/*

The * is a wildcard to catch any assembly beneath that path. Click Next .

Now you can pick a permission set for your new code group. For now, pick Internet . It's quite a restrictive set, similar to a Java applet sandbox. Click Next and Finish .

Now right-click on your new code-group and select Properties. In the General tab, ensure the topmost checkbox is selected, then click OK.

Now, any .NET assemblies that are loaded from a location beneath the URL you specified will have the Internet permission set applied to them. Expect to get some SecurityExceptions if you haven't written your code to carefully observe the reduced permission set.

Sorry this is a long description. It really is a lot more simple than it sounds.

Answer 4

The functionality you're looking for is built-in into visual studio :

On the security tab of your project, there's an "Advanced ..." button which let you configure whether you want to debug in full trust, or on a specified trust level.