.NET Security Blog : SSCLI

Special Permissions in the SSCLI

shawnfa — Tue, 06 Jun 2006 19:00:00 GMT

Before digging into a pretty clever optimization that the SSCLI makes for certain special permission demands, I want to point out that everything I’m about to cover is an implementation detail. Although this optimization does occur today, we can and will change it for future versions of the CLR (and potentially service packs for the v2.0 version) … the only thing guaranteed about the behavior of a demand is that it throws a SecurityException if the call stack does not meet the required permissions; and does nothing if it does.

With that being said, the v2.0 CLR has a few special permissions which it can apply a clever optimization to in order to speed up demands. If you’ve got the SSCLI v2 installed, you can see these permission defined in managed code in the PermissionType enumeration (clr\src\bcl\System\Security\CodeAccessSecurityEngine.cs) and mirrored in the VM (clr\src\VM\SecurityPolicy.h). (Look for the set of #defines starting at line 297 with SECURITY_UNMANAGED_CODE).

There are two categories of these special permissions defined:

A flag of a permission (Assert, SkipVerification, UnmanagedCode, etc)
An unrestricted permission (UI, Environment, Security, etc)

Each of these is given an integer value in SecurityPolicy.h which matches its value in the PermissionType enumeration. The CLR maps these values into flags by using the corresponding bit of a DWORD to indicate that this permission is the one being talked about. For instance, given:

#define UI_PERMISSION 9

We use 1 << UI_PERMISSION or 0x00000200 as a flag to indicate that we’re referencing unrestricted UI permission. In this way, we can simply logically or together as many of these permissions as is needed to talk about any given set of the special permissions. This does imply a limit of 32 special permissions however -- currently the CLR defines only 18, so there is plenty of room to grow there. One interesting thing to note is that although we do define SECURITY_FULL_TRUST to be bit 7, generally the VM uses 0xFFFFFFFF to refer to the FullTrust special permission bitmask.

Calculating Special Permission Flags

When an assembly or an AppDomain is loaded, policy is resolved to get the grant set. The entry point for this resolution is SecurityPolicy::ResolvePolicy (clr\src\VM\SecurityPolicy.cpp), which takes the parameters you would expect such as the evidence and assembly level declarative permission sets. It returns the grant set, and as an out parameter the denied permission set. As an extra out parameter, dwSpecialFlags, is the set of special permission flags which are calculated from the grant and deny set.

The logic is to return a bitmask that represents everything that was in the grant set and not in the deny set. So if an assembly was being resolved in SecurityPolicy::ResolvePolicy, and its grant set included SkipVerification, UnmanagedCode and unrestricted UIPermission while its deny set included SkipVerification and unrestricted EnvironmentPermission, the output would be:

((1 << SECURITY_SKIP_VER) | (1 << SECURITY_UNMANAGED_CODE) | (1 << UI_PERMISSION) ) &
    ~( (1 << SECURITY_SKIP_VER) | (1 << ENVIRONMENT_PERMISSION) ) = 
(0x00000103) & !(0x00000402) = 
0x00000103 & 0xFFFFFBFD = 
0x00000101 = 
(1 << UI_PERMISSION) | (1 << SECURITY_UNMANAGED_CODE) 

Which is what we would expect when you take the set (SkipVerification, UnmanagedCode, UIPermission) and remove (SkipVerification, EnvironmentPermission).

The actual work of resolving policy and calculating these flags is delegated by SecurityPolicy::ResolvePolicy to System.Security.SecurityManager.ResolvePolicy (clr\src\bcl\System\Security\SecurityManager.cs). After ResolvePolicy computes the grant and deny sets, it passes those to SecurityManager.GetSpecialFlags, whose job it is to do the mapping from the permission sets to any appropriate special permission flags. It does this by scanning for any flags on permissions which have their flags represented in the special permissions (currently just SecurityPermission and ReflectionPermission) and saving those flags away. It also does a scan for any permissions which have their unrestricted permissions set as a special flag, saving those as well.

Once all the permissions which may map to a special flag are found, SecurityManager.MapToSpecialFlags is called to map the flags from SecurityPermission and ReflectionPermission back to an appropriate flag, while the GetSpecialFlags method itself adds bits for any of the other permissions which are unrestricted.

I mentioned earlier that FullTrust is represented as 0xFFFFFFFF rather than 0x00000080, you can see that mapping in the very first line of SecurityManager.GetSpecialFlags.

Security Descriptors and Special Permissions

The base SecurityDescriptor class (clr\src\VM\SecurityDescriptor.h) defines a protected member, the DWORD m_dwSpecialFlags, which holds the set of special permission flags that apply to the VM object the security descriptor refers to (such as an AppDomain or Assembly). In addition to this set of flags, the ApplicationSecurityDescriptor (clr\src\VM\SecurityDescriptorAppDomain.h) defines a second member to hold these flags -- m_dwDomainWideSpecialFlags.

The m_dwSpecialFlags member is populated with the result from calling SecurityPolicy::ResolvePolicy on the object being loaded. The extra field in the ApplicationSecurityDescriptor however is kept up to date differently, and allows us to perform an optimization when a demand for one of these special permissions comes in.

After the AppDomain has had its policy resolved, m_dwDomainWideSpecialFlags is initialized to match the special flags of the AppDomain. (This is done in ApplicationSecurityDescriptor::InitializePLS in clr\src\VM\SecurityDescriptorAppDomain.cpp). This means an AppDomain with no loaded assemblies has an m_dwDomainWideSpecialFlags indicating the special permission grant set of the domain itself.

As each assembly is loaded into the AppDomain, the AssemblySecurityDescriptor’s m_dwSpecialFlags is initialized while policy is resolved on that assembly. (See AssemblySecurityDescriptor::ResolveWorker in clr\src\VM\SecurityDescriptorAssembly.cpp). The AppDomain then updates the m_dwDomainWideSpecialFlags field with the information from the AssemblySecurityDescriptor in ApplicationSecurityDescriptor::AddNewSecDescToPLS. The domain wide flags are updated by doing a bitwise and between the current domain wide flags and the flags of the assembly’s security descriptor.

Following this logic along, the domain wide special flags start out as the set of special permissions granted to the AppDomain itself, and then are potentially reduced by each assembly loaded so that at any given point the domain wide special flags are always the set of special permissions which are granted to every assembly in the domain as well as the domain boundary.

With that setup, if a demand for one of the special permissions is done in the AppDomain, we can check to see if the domain wide flag for that permission is set. If it is, then the CLR can cause the demand to succeed without ever having to do a stack walk, since it knows that for the special permission bit to be set everything in the AppDomain must be granted the given permission. The code which maps the permissions in a demand to a set of special flags is in SecurityStackWalk::GetPermissionSpecialFlags (clr\src\VM\SecurityStackWalk.cpp).

Obviously this optimization does not work in the face of stack walk modifiers such as Deny or PermitOnly, which can cause the permission set of the call stack to become a subset of the permissions granted to the assemblies in the domain -- and if you look at the code in SecurityStackWalk::HasFlagsOrFullyTrustedIgnoreMode (clr\src\VM\security.inl) this is what the check for pThread->GetOverridesCount() == 0 is doing. [But as Alton Brown might say, that’s another show.] This is just one more reason that you really want to avoid using Deny and PermitOnly in your code if at all possible.

Also note that this logic works for determining if a demand will pass, however it cannot be used to determine that a demand will fail. For instance, if an AppDomain has assemblies A, B, and C loaded into it, and the AppDomain, assembly A, and assembly B are all granted SkipVerification while assembly C is not, the SECURITY_SKIP_VER bit will be clear on the domain wide flags. However, if a skip verification demand is done while only A and B are on the call stack (or if C is on the stack, but either A or B has done an Assert preventing a stack walk from reaching C), then the demand will still succeed even though the bit is clear.

The take away from this is not that you should try to only demand special permissions -- again, these were all implementation details subject to change at any point. You should always demand the most appropriate permission for the resource you’re trying to protect. More importantly, it’s interesting to see how the CLR can optimize the performance of some demands, and how operations like Deny and PermitOnly can ruin the optimizations.

SSCLI Zone Mappings

shawnfa — Tue, 16 May 2006 17:00:00 GMT

My previous post is begging the question "so what is the SSCLI's zone mapping policy?"

It's actually quite simple, the source for SecurityPolicy::QuickGetZone in clr\src\vm\securitypolicy.cpp shows that SSCLI maps a URL to:

NoZone if the URL is NULL
MyComputer if the URL is a file URL
Internet for all other cases

Which indicates that there is no such thing as LocalIntranet, Trusted or Untrusted zones in SSCLI land. (Although the SecurityZone enumeration still contains those as you can see in clr\src\bcl\system\security\securityzone.cs).

The check to see if the URL is a file URL is simply done as a call to the UrlIs API specifying URLIS_FILEURL. For those non-Win32 platforms, the PAL version of UrlIs can be found in the palrt\src\urlpars.cpp file.

Custom Zones and the CLR

shawnfa — Mon, 15 May 2006 20:30:00 GMT

On the topic of zones and the CLR ...

Windows lets you define custom zones outside of the standard ones that the CLR knows about (see MSDN's topic on Security Zones for more information). However, because the CLR doesn't know about them, generally any assembly loaded from one of those zones will not get any CAS permissions. This stems from the fact that default policy starts by switching on which zone an assembly is loaded from; since the custom zone won't have a matching ZoneCodeGroup it will end up with Nothing.

The CLR does provide a registry key to help out in this scenario however. If you set the DWORD HKLM\Software\Microsoft\.NETFramework\<version>\Security\Policy\TreatCustomZonesAsInternetZone to 1, the CLR will give any assembly loaded from a zone it doesn't recognize Internet zone evidence.

In the SSCLI, the source for this feature lives in clr\src\utilcode\overrides.cpp -- check out the ApplyCustomZoneOverride function. This function takes in a pointer to what the CLR currently thinks the zone is, and if the above registry key is set, switches that value to be Internet.

An interesting quirk is that this is not actually wired up in the default SSCLI, since it's implementation of zone mapping is much simpler than the standard CLR. If you do want to beef up the zone mapping logic, and potentially wire in a call to ApplyCustomZoneOverride you'll want to check out SecurityPolicy::QuickGetZone in the clr\src\vm\securitypolicy.cpp file.

What Happens When You Fully Sign a Test Signed Assembly

shawnfa — Tue, 04 Apr 2006 00:44:00 GMT

When an assembly is test signed, the public key used to verify its signature is different from the public key that makes up part of the assembly identity. So what happens when you take an assembly which is registered as a test signed assembly on your machine and fully sign it?

The key here (aren't puns fun) is the fully signed bit in the CLR header. An assembly which is fully signed (so not simply named, test signed, or delay signed) has the COMIMAGE_FLAGS_STRONGNAMESIGNED bit set in the Flags field of the IMAGE_COR20_HEADER. (Both can be found in corhdr.h in the Framework SDK)

If the CLR is verifying a signature, and it sees this bit set, it won't even attempt to check the skip verification or test sign lists. Instead, verification proceeds with the public key embedded in the assembly itself. So the answer to the question is that a fully signed assembly with a entry on the test signed assembly list will work as expected, and verify with the correct public key.

In the SSCLI v2, you can see this behavior in the strong name code located at sscli20\clr\src\VM\strongname.cpp. Specifically, go to the VerifySignature method -- the relevant code starts at line 2498. On 2504 we check to see if the fully signed bit is in place, and if not we check for a test public key on 2506. The magic behind test key signing is essentially on one line of code, line 2514, where we substitute the test public key for the assembly's real public key.

SSCLI v2

shawnfa — Fri, 24 Mar 2006 19:18:00 GMT

As Jason announces, v2.0 of the SSCLI is now available for download: http://msdn.microsoft.com/net/sscli.

In addition to general CLR features like generics that are available in this download, some interesting security points to look at are:

Transparency (sscli20\clr\src\vm\securitytransparentassembly.cpp)
Revamped compressed stack (sscli20\clr\src\vm\newcompressedstack.cpp)
New declarative security metadata format (sscli20\clr\src\vm\securitydeclarative.cpp)

And of course our general security perf work is here too. For those interested in how this mscorwks thing works ... time to get downloading :-)

Comparing Java and .NET Security

shawnfa — Wed, 17 Aug 2005 21:34:00 GMT

It's been a while since I've last seen a comparison of Java and .NET security. Nathaneal Paul and David Evans from the University of Virginia Computer Science Department recently finished their comparison, Comparing Java and .NET Security: Lessons Learned and Missed.

In their paper, Nathaneal and David take a bottom up approach to examining the security models of each platform. They start with the opcodes that make up the instruction set of each virtual machine, and examine them both from an instruction set design perspective as well as from a verification perspective. They use the SSCLI to compare verifier implementations between the CLR and Java. From there, they look at the way each platform allows for policy creation and the permissions that each uses. The paper ends with an examination of how each platform uses its policy system, from bootstraping to modifying the stack walk.

At the beginning of the paper, Nathaneal and David compare the number of reported major security vulnerabilities in the Java VM and the CLR since each had their official 1.0 release in January 1996 and January 2002 respectively. Their data makes for an interesting graph, presented in their paper as Figure 1:

When is ReflectionPermission Needed?

shawnfa — Tue, 08 Mar 2005 20:31:00 GMT

Reflection and its interaction with security can sometimes be a bit of a confusing matter. The easiest portion to figure out is the permissions needed to use Reflection.Emit. In order to do anything with the reflection emit feature, you'll need to have ReflectionPermission with the ReflectionEmit flag set. In the default policy, you'll have this permission if you're running on LocalIntranet or MyComputer.

Things get a little more dicey when you start to figure out what permissions you need in order to use standard reflection. The general rule of thumb is that if you could do something with early binding, then you won't need ReflectionPermission in order to use reflection to do the same thing with late binding. So, you could easily create an XmlDocument and load a string into it with the Load method via reflection, even if you didn't have any ReflectionPermission. This makes sense because demanding a permission here really doesn't buy any extra security, since you could have just done these operations directly in your code anyway.

Getting a Type object for a type that is not visible to you, or getting an object to represent a member that is not visible has different behavior between v1.x and v2.0. On v1.x, you'll need ReflectionPermission with the TypeInformation flag. This means if you want to get a Type object for System.AssemblyHandle (which is a type in mscorlib marked as internal), you'll need this permission. You'll also need this permission to get a MethodInfo object for System.Array::GetMedian() even though Array is public, since GetMedian() is a private member. The same holds true of getting a FieldInfo for System.Security.PermissionSet::m_Unrestricted, a private field. Getting a PropertyInfo for the protected property System.Security.Cryptography.HashAlgorithm::HashSize would not require any permissions if you derived from HashAlgorithm, otherwise TypeInformation would be needed there as well. One thing that's interesting to note about this is that if you do not have TypeInformation, and you try to perform one of these protected operations, you won't get a SecurityException. Instead, reflection will just return a null object back to you. In Whidbey the TypeInformation flag has been marked as obsolete, and any code can get at these objects.

The reason this is safe is that once you have the appropriate xxxInfo object, and you want to either invoke it or read its value, you'll need ReflectionPermission with the ReflectionPermissionFlag.MemberAccess flag set. By default, both TypeInformation and MemberAccess are only granted to code running on the local machine.

So, from the discussion above, it would seem that I could easily call System.Reflection.Assembly::GetExecutingAssembly() from partial trust code, since Assembly is a public class, and GetExecutingAssembly() is a public method on that class. However, if I tried to do that, I would end up with a SecurityException.

Why is that? The answer lies deep within the CLR, inside the reflection internals. If you look inside the SSCLI, you can find the code that's responsible for dispatching the late-bound call in COMMember::InvokeMethod_Internal (located in sscli\clr\src\vm\COMMember.cpp, line 1154). Scanning down a bit through that method, there's an interesting comment on line 1231, where the reflection system calls an IsDangerousMethod() function to check to see if it needs to demand additional permissions. If IsDangerousMethod() returns true, then an RM_ATTR_RISK_METHOD flag gets set, which causes COMCodeAccessSecurityEngine::SpecialDemand(REFLECTION_MEMBER_ACCESS) to be called on line 1278.

It seems pretty obvious that this might be our problem, so lets go check out IsDangerousMethod() to see what it considers to be dangerous. This function starts at line 1007 of COMMember.cpp, and the meat of it is between lines 1073 and 1093. Basically, we check the method table of the method in question, and compare it to a method table of several classes. If the method belongs to one of these classes, we consider it dangerous and return true. The list of classes to compare against is initialized on lines 1031 to 1049. The 19 special classes are:

System.Activator	System.AppDomain
System.RuntimeType	System.Type
System.IO.IsolatedStorage.IsolatedStorageFile	System.Reflection.Assembly
System.Reflection.ConstructorInfo	System.Reflection.EventInfo
System.Reflection.FieldInfo	System.Reflection.MethodBase
System.Reflection.PropertyInfo	System.Reflection.RuntimeConstructorInfo
System.Reflection.RuntimeEventInfo	System.Reflection.RuntimeFieldInfo
System.Reflection.RuntimeMethodInfo	System.Reflection.RuntimePropertyInfo
System.Reflection.Emit.AssemblyBuilder	Sytem.Reflection.Emit.MethodRental
System.Resources.ResourceManager

This table is defined in terms of macros that look like CLASS__APPDOMAIN, which should all be relatively easy to figure out on their own. However, if you'd like to find the source of this definition, you can check clr\src\vm\mscorlib.h, where all of these macros are created. For instance, CLASS__APPDOMIAN is created on line 64 of this file:
DEFINE_CLASS(APP_DOMAIN, System, AppDomain)

If a class belongs to this table, then none of its methods or properties are available through late binding unless the calling code is granted MemberAccess. That's why my partial trust code above couldn't call Assembly::GetExecutingAssembly().

In addition to the 19 classes listed above, Whidbey adds the following four classes to the dangerous list:

System.RuntimeFieldHandle	System.RuntimeMethodHandle
System.RuntimeTypeHandle	System.Reflection.RuntimeFieldInfo

Another area where reflection and security come together is when the target code is protected with a LinkDemand. The problem with using reflection to invoke a method that contains a LinkDemand is that the reflection code and not your code will ultimately be the method's caller. This means that if the LinkDemand is for a set of CAS permissions (FullTrust for instance), it may be satisfied by the reflection code which lives in mscorlib, even though the demand may not have been satisfied by your code. In order to prevent malicious code from circumventing LinkDemands through the use of reflection, invoking a method through reflection has the effect of turning LinkDemands into full demands. If you don't want the whole stack checked, then you should Assert the permissions being demanded before calling the method with reflection, and then RevertAssert those permissions after the method returns. By following that pattern, you can most closely simulate the effect of the LinkDemand.

For instance, if I'm calling System.Security.Cryptography.X509Certificates.X509Certificate::Handle, which has a LinkDemand on its getter for UnmanagedCode, I would use something like this:

IntPtr handleValue = IntPtr.Zero;
try
{
    new SecurityPermission(SecurityPermissionFlag.UnmanagedCode).Assert();
    handleValue = (IntPtr)handleProperty.GetValue(cert, null);
}
finally
{
    CodeAccessPermission.RevertAssert();
}

To sum up, when working with reflection, if you keep the following rules in mind, you shouldn't run into any issues:

If you're using Reflection.Emit, you need ReflectionPermissionFlag.Emit
If you're accessing code that you would be able to access anyway, you don't need any permission
If you're getting objects describing items you don't have access to, you need ReflectionPermissionFlag.TypeDiscovery
If you're invoking objects you don't have access to, you need ReflectionPermissionFlag.MemberAccess
There are some special classes unavailable without ReflectionPermissionFlag.MemberAccess
All LinkDemands will turn into full Demands

Why == and the Equals Method Return Different Results for Floating Point Values

shawnfa — Mon, 19 Jul 2004 20:21:00 GMT

There's a subtle difference between comparing floating point values with the Equals method and comparing them with the == operator. (In all the code I show in this post, I use the Double class, however everything I say also applies to the Single class).

When the following code is run, it compiles and produces the results you would expect:

double pi1 = 3.1415926535;
double pi2 = 3.1415926535;

Console.WriteLine("For PI:\n\tDouble.Equals() : {0}\n\tOperator == : {1}",
    Double.Equals(pi1, pi2),
    pi1 == pi2);

For PI:
    Double.Equals() : True
    Operator == : True

Both values of pi compare to be the same regardless of using the Equals method or operator. However, the following code produces a more interesting result:

double nan1 = Double.NaN;
double nan2 = Double.NaN;
        
Console.WriteLine("For NaN:\n\tDouble.Equals() : {0}\n\tOperator == : {1}",
    Double.Equals(nan1, nan2),
    nan1 == nan2);

When this is run, the results are:

For NaN:
    Double.Equals() : True
    Operator == : False

Why would Double.Equals() produce a result of true, while the == operator produces a result of false? Well, to start with, lets check out what a Double is. According to section 7.2 of the ECMA spec (in Partition II):

Class Library Type	CIL Type	Description
System.Single	float32	IEC 60559:1989 32-bit float
System.Double	float64	IEC 60559:1989 64-bit float

So what's this IEC 60559:1989 stuff? It's a standard for the binary format of floating point types. The C# Standard points out in section 3 that this standard is more commonly known in the United States as ANSI/IEEE Standard 754-1985, or the IEEE Standard for Binary Floating-Point Arithmetic.

According to IEC 60559:1989, two floating point numbers with values of NaN are never equal. However, according to the specification for the System.Object::Equals method, it's desirable to override this method to provide value equality semantics. Since System.ValueType provides this functionality through the use of Reflection, the description for Object.Equals specifically says that value types should consider overriding the default ValueType implementation to gain a performance increase. In fact from looking at the source of System.ValueType::Equals (line 36 of clr\src\BCL\System\ValueType.cs in the SSCLI), there's even a comment from the CLR Perf team to the effect of System.ValueType::Equals not being fast.

So now we have two conflicting ideas of what Equals should mean. Object::Equals says that the BCL value types should override to provide value equality, and IEC 60559 says that NaN does not equal NaN. Partition I of the ECMA spec provides resolution for this conflict by making a note about this specific case in section 8.2.5.2.

“Note: Although two floating point NaNs are defined by IEC 60559:1989 to always compare as unequal, the contract for System.Object.Equals, requires that overrides must satisfy the requirements for an equivalence operator. Therefore, System.Double.Equals and System.Single.Equals return True when comparing two NaNs, while the equality operator returns False in that case, as required by the standard.”

So that's why == and Equals behave differently in the NaN case. There are a lot of issues to remember when dealing with floating point numbers, and this should be another one. Always use Equals() if you want NaN to be equal with other NaNs, and always use the == operator if you want NaNs to behave according to the IEEE floating point specification.

What's the Deal with the ECMA Key?

shawnfa — Wed, 09 Jun 2004 23:35:00 GMT

The libraries laid out in the ECMA spec are all signed with a public key that looks pretty strange. If you ildasm mscorlib.dll, System.dll, or any of the other framework libraries that are defined in the ECMA specs (see partition IV: Library if you're interested in which libraries these are), you'll notice a peculiar looking public key:

.publickey = (00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 )

That looks very strange, and not at all like a strong key. This key is called the Standard Public Key (sometimes referred to as the ECMA public key), and has a public key token of b77a5c561934e089. If you have the SSCLI installed, you'll see this key defined as the “neutral key” in the file sscli\clr\src\dlls\mscorsn\strongname.cpp. (lines 107 and 109).

By looking at the format of public key blobs, defined in strongname.h (line 38 in sscli\clr\src\inc\strongname.h in the SSCLI, line 28 of <SDK root>\inc\strongname.h in the .NET Framework 1.1 SDK), you'll see it's defined as follows:

// Public key blob binary format.
typedef struct {
  unsigned int  SigAlgID;     // (ALG_ID) signature algorithm used to create the signature
  unsigned int  HashAlgID;    // (ALG_ID) hash algorithm used to create the signature
  ULONG        cbPublicKey;  // length of the key in bytes
  BYTE         PublicKey[1]; // variable length byte array containing the key value in format output by CryptoAPI
} PublicKeyBlob;

So, the standard public key actually has 0 for both algorithm IDs, a length of 4 bytes, and all of those bytes are set to 0. This means that the standard public key is actually a 16 bit key of all zeros.

The mechanism behind this key is actually pretty clever. Since the ECMA spec lays out the specifications for how any implementation of the CLI should work, it can't say that everyone must sign with the Microsoft key. If it did that, then Microsoft would either have to sign anyone's assemblies who decided to implement the CLI, or we'd have to make our private key available to the general public, creating a huge security hole. However, since strong names of referenced assemblies are burned into assemblies at compile time, there needs to be some way for compiler to refer to the standard libraries without forcing a specific implementation of the CLI onto the users of the assembly.

Enter the standard public key. Assemblies that specify this key as their public key aren't actually signed by a corresponding private key. Instead, CLI implantations see this key, and substitute in their own keypair. For instance, when the SSCLI sees the standard public key, it knows that this means the assemblies have been signed with the key found in sscli\clr\src\dlls\mscorsn\thekey.h and sscli\clr\bin\finalpublickey.snk.

Allowing CLI implementors to swap the actual key that the standard public key represents frees them up to be able to run code that was compiled against another vendor's CLI implementation. Also, since each VM implementation will translate the standard public key into only their private keypair, this prevents assemblies signed by creators of CLI implementations from verifying on different CLI implementations. For instance, the Mono mscorlib won't pass signature verification on the CLR.

Same Site Socket Permission

shawnfa — Wed, 10 Mar 2004 22:09:00 GMT

Fairly frequently, people will want to know how to get same site socket permissions, in the same way that they can get same site web permission today. Unfortunately, the answer is that with the security objects shipped with the framework, there is no way to accomplish this.

In order to figure out what coding must be done to get same site socket permissions, first lets look at how same site web permissions are granted. Instead of being a flag on the web permission itself, same site web permission is actually created in the NetCodeGroup. The SSCLI source for this code group can be found here: http://dotnet.di.unipi.it/Content/sscli/docs/doxygen/fx/bcl/netcodegroup_8cs-source.html. This code group, instead of having a static permission set associated with it, creates a dynamic permission set when it is evaluated. If its membership condition is matched, the Resolve method of the code group will scan the evidence for a Url or Site object. If it finds one of these (giving preference to Url), it will generate a WebPermission with access back to that Url. (You can see this by looking at the Resolve method, the interesting part is between lines 82 and 104).

In order to create same site socket access, something very similar would have to be done. However, careful inspection of the NetCodeGroup.cs source file shows that this work is already done for you! The implementation details of generating the dynamic permissions are encapsulated in the CalculatePolicy method (line 284). Interestingly enough, on line 289, a security element named socketPerm is initialized to null, and then ignored for the rest of the method. So it looks like all that needs to be done is to write a method that will create the socket permissions for you. The NetCodeGroup has this method written already as well. Specifically, there's a CreateSocketPermission method on line 225 that does the job for you.

So, in order to modify the NetCodeGroup to create same site socket permissions, all that needs to be done is to change line 289 from:

SecurityElement socketPerm = null;

SecurityElement socketPerm = CreateSocketPermission(host, scheme);

And there you go, a NetCodeGroup that will grant both same site web and same site socket permissions.

If you're looking for the NetCodeGroup.cs file in the SSCLI distribution, it unpacks to the clr\src\bcl\system\security\policy directory.

More Details on Portable Crypto Operations

shawnfa — Wed, 10 Mar 2004 00:33:00 GMT

Yesterday I posted about detecting which CSP provided algorithms were available on your copy of Windows, and upgrading IE to get a newer CSP that supported more algorithms. Sebastien Pouliot provied some nice followup information on using pure managed classes instead of the *CryptoServiceProvider implementations to help solve the portability problem.

Sebastian works with Mono, and points out that all of their algorithms are pure managed, and can be used on any platform (even the ones named *CryptoServiceProvider, the names are just for compatibility). Microsoft also provides several managed classes, notably RijndaelManaged for AES symmetric encryption, and SHA1Managed for hashing, so using the Microsoft framework is also an option here. For updates on the status of Crypto in Mono, you can check out http://www.go-mono.com/crypto.html

What follows is part of Sebastian's response to yesterday's post (note Fx1.2 is Whidbey, v2.0 of the Framework):

Actually all Fx cryptographic algorithms are supported, including the new one in Fx1.2 - and them some...

The mscorlib.dll assembly contains the following algorithms.
- DSACryptoServiceProvider *
- RSACryptoServiceProvider *, **
- DESCryptoServiceProvider *
- RC2CryptoServiceProvider *
- RijndaelManaged
- RIPEMD160Managed ***
- SHA1CryptoServiceProvider *, ****
- SHA1Managed ****
- SHA256Managed
- SHA284Managed
- SHA512Managed
- TripleDESCryptoServiceProvider *
and all HMAC (SHA1, MD5, RIPEMD160, SHA256, SHA384, SHA512)

* For compatibility we had to keep the <algo>CryptoServiceProvider names but the implementations are fully managed.
** Support both PKCS1 and OAEP padding.
*** To support upcoming Fx 1.2
**** They are actually the same implementation.

Mono.Security.dll assembly also have some additional algorithms*
- RSAManaged
- DHManaged
- ARC4Managed **
- MD2Managed ***
- MD4Managed ***
which were required for other "internal" pieces like NTLM authentication and SSL/TLS (both available as managed implementation inside the same assembly).

* Note the absence of DSAManaged from this assembly! Sadly the DSA abstract class has an internal constructor making it impossible to inherit from it outside mscorlib. I hope this get corrected in Fx 1.2.
** Compatible with RSA RC4 stream cipher.
*** MD2Managed and MDManaged are present but we STRONGLY discourage their use in new applications. Their presence was required to support older X.509 certificates (signed using a MD2 hash) and to support NTLM authentication (which use MD4).

> Also, how easy would it be to get the Mono algorithms to compile using the Microsoft toolset and distribute them with an application? Would I need just a .cs file or two, or are there a slew of dependencies to worry about?

Using Mono.Security.dll on Windows should be very easy (i.e. it shouldn't require any change or I missed my target ;-).

Other algorithms (corlib) may have dependencies on BigInteger (DSA, RSA) and other internal classes from Mono.* namespaces. However they do not depend on some Mono's internal (with the notable exception of the RNGCryptoServiceProvider class) so it's only a matter to include the right files. Some people ported the corlib's source for the Compact Framework without too much problems (few changes were required because many overloaded methods are missing in CF).

The licensing is also very friendly as Mono class library use the MIT X.11 license (http://www.opensource.org/licenses/mit-license.php). Finally anyone can follow the current status of Mono's cryptography by bookmarking this page: http://www.go-mono.com/crypto.html

How Exceptions Work in Rotor (and the CLR)

shawnfa — Sat, 06 Mar 2004 02:30:00 GMT

Joel Pobar has a nice post with Jan Kotas' explanation of how exceptions work in Rotor (and by extension, the CLR).

Moving

shawnfa — Wed, 10 Dec 2003 03:29:00 GMT

The GotDotNet blogs are being frozen, so I'll be moving my blog over to the ASP.Net site. You can find the new location at http://blogs.msdn.com/shawnfa

Custom Security Object Samples

shawnfa — Tue, 11 Nov 2003 00:46:00 GMT

Currently, there are no samples on MSDN for creating custom security objects. However, the SSCLI ships with implementations for all of the built in security objects that shipped with the .Net framework 1.0. This source can be used as a sample to help along with custom security object creation. The Universita Di Pisa has posted the source code for the SSCLI on their website, so you don't even have to download the package to view it. Here are some links that may be useful:

SSCLI home page
Online SSCLI source browser
AllMembershipCondition.cs (A simple membership condition)
StrongNameMembershipCondition.cs (A more complete membership condition)
UnionCodeGroup.cs (A sample code group)
FileIOPermission.cs (A permission that works on a list of strings)
SecurityPermission.cs (A permission that works on a set of flags)

Update (11/14/03): Eugene has just posted a sample of creating a custom permission: http://blogs.gotdotnet.com/eugenebo/PermaLink.aspx/069af686-c063-4ce4-9cac-6b8d5234918e