关于AppDomain中evidence参数作用及相关问题的技术问询

Hey there, let's unpack your questions about the evidence parameter in AppDomain creation—this is a key piece of .NET's code access security (CAS) model, so it's totally normal to feel fuzzy on it at first.

1. What's the exact role of the evidence parameter? #

Think of evidence as a set of "identity tags" you pass to the CLR when creating an AppDomain. These tags tell the CLR where the code comes from and who it is, so the runtime can decide what permissions to grant it.

Common evidence types include:

• Zone: Whether the code is from the local machine, intranet, internet, or a restricted site
• StrongName: The strong name signature of the assembly (if signed)
• Publisher: The digital signature of the code's publisher
• Url: The original download URL of the assembly

The CLR uses this evidence to match against its security policy rules and assign a corresponding permission set to the AppDomain. For example, code marked with the Internet zone evidence gets a very restricted permission set by default, while local machine code gets full trust.

2. Is the evidence parameter required? How does it differ from permission sets? #

Is it required? #

Nope—you can pass null when creating an AppDomain. If you do, the CLR will generate a default evidence set for the new domain, usually inherited from the hosting AppDomain's evidence. But this is rarely ideal for sandboxing, since you lose control over the identity context of the sandboxed code.

Difference from permission sets #

• Evidence is the input: It's the metadata that tells the CLR "what this code is/where it's from." The runtime uses this to calculate which permissions the code should get (unless you explicitly specify a permission set).
• Permission sets are the output: They're the actual list of allowed operations (e.g., can access the file system? Can make network calls?). You can either let the CLR calculate this based on evidence, or explicitly specify a permission set when creating the AppDomain.

If you explicitly pass a permission set to CreateDomain, the evidence's role shifts from permission calculation to identity validation. For example, you might use evidence to verify that the sandboxed assembly matches a specific strong name before granting it your custom permission set.

3. Do I need to adjust the evidence parameter in my sandbox UI? Should it change per .exe? #

This depends on your sandbox's goals:

• If you want CAS to enforce context-based permissions: Yes, you should adjust evidence per .exe. For example, if a user loads an .exe downloaded from the internet, you should extract its Zone evidence (Internet) and pass that to the AppDomain—this tells the CLR to apply the default restricted internet permissions. For a local .exe, you might use MyComputer zone evidence for more lenient permissions (or still restrict it if that's your sandbox's purpose).
• If you're using a fixed, custom permission set: No, you don't need to change evidence per .exe. You can pass a static evidence set (or even null) because you're explicitly defining what the code can do, rather than letting CAS calculate permissions from evidence.

A common pattern for sandboxes is to extract evidence from the target assembly itself (using Assembly.Evidence on the loaded assembly) and pass that to the new AppDomain, ensuring the runtime applies the appropriate security context based on the code's actual origin.

内容的提问来源于stack exchange，提问作者charliezz10