I'm new C# and am trying to understand the new security features of .NET-4.
To fill in some details, I'm currently trying to update AutofacContrib.Moq to work with the latest Moq. I had no problems doing this for .NET-3.5 and under. But in .NET-4 the security restrictions result in numerous security exceptions.
Moq has a a single method, GetObjectData, that's marked with the SecurityCritical attribute. AutofacContrib.Moq has the AllowPartiallyTrustedCallers attribute set which is the source of the exceptions. It seems that rather than adding the SecurityRules attribute with a SecurityLevel of 1, I'd be better off removing AllowPartiallyTrustedCallers attribute. I believe this makes the assembly SecurityTransparent by default, which may not be sufficient (though the AutofacContrib.Moq unit tests pass).
My main question at the moment is whether assemblies targeting .NET-4 should ever use the AllowPartiallyTrustedCallers attribute? But, given that I definitely don't understand everything yet, what details should be considered when working with assemblies that are security marked? Do I need to explicitly mark my assembly with security attributes in those places it uses, directly or indirectly, something that's marked SecurityCritical?
You are correct: in .NET 4, leaving the APTCA on there makes the assembly SecurityTransparent, and that may be what's causing you grief.
The MSDN article Migrating an APTCA Assembly to the .NET Framework 4 has a good discussion and explanation of the changes to the AllowPartiallyTrustedCallersAttribute in .NET 4.
Specifically:
The AllowPartiallyTrustedCallers attribute has changed. In v4, it no longer has anything to do with link demands. In fact, the implicit link demand that was present on signed libraries in v2 is gone. Instead, all fully trusted assemblies in v4 are, by default, SecurityCritical.
[snip /]
In v4, the effect of APTCA is to remove the automatic SecurityCritical behavior from the assembly to which it’s applied.
And...
Because the AllowPartiallyTrustedCallers attribute causes the entire assembly to be SecurityTransparent by default, the assembly’s author must specifically mark methods needing to perform privileged operations as SecurityCritical or SecuritySafeCritical.
(It's really a good article that author Mike Rousos did a great job with. I encourage you to read it in its entirety.)
If you're starting a new .NET 4 library, it's probably best to stick with the .NET 4 security model and use the appropriate SecurityCritical, SecuritySafeCritical, and SecurityTransparent attributes where needed. They're far easier to manage and understand than old code access security.
If you're migrating an old library to the new model, there's a good example in the article of how to do that... but basically it amounts to removing old LinkDemands and adding [SecurityCritical] in their place.
In your particular case, the fastest way to get going would be to add the SecurityRules attribute so you get the old behavior, but I'm not sure I'd consider that the right way. The right way would probably be to lose the APTCA and add SecurityCritical on the assembly because the assembly may contain SecurityCritical code, then mark the various types that call SecurityCritical code (e.g., stuff that references GetObjectData) with SecuritySafeCritical so your SecurityTransparent code can call it. Of course, that second approach will be a lot more work, so you'll probably want to run SecAnnotate.exe and get some automated tips.
Looking at the Moq trunk, a search for GetObjectData shows that the method in question is the override for an exception serialization mechanism (ISerializable.GetObjectData on System.Exception), which only SecurityCritical code will be calling anyway, so you may not even run into any trouble if you just lose APTCA and mark the assembly SecurityCritical.
There is an issue filed on Autofac to update it to the latest security model. If you like the idea, go vote/comment on it.
Sorry that wasn't a short answer. Security is, unfortunately, never easy. :S
Related
Let me clarify:
I have built a class library to be used in several projects. As part of this DLL I want to add a few different custom providers for Owin Cookies by extending CookieAuthenticationProvider so I need to include a reference to Microsoft.Owin.Security.Cookies. This is safe because the newer projects that will use my library also use Microsoft.Owin.Security.Cookies.
However some of the projects are older and dont use Owin etc... Will they blow up if I include the library for other use? Or will they only blow up if I try to use the provider (which I wouldn't since they cant use it).
I want to put some commonly used things in my library without having to reference every one of it's dependent DLL's to every project that uses them. I'm pretty sure what I'm doing is ok but I was hoping somone could tell me before I waste many hours going forward with this. Also if there is a better way I'm all ears.
The rules:
All types which are visible to a given assembly must be declared in assemblies referenced by that assembly.As long as your class library does not actually expose in its public API the types found in the Microsoft.Owin.Security.Cookies assembly, then other assemblies can safely compile with your DLL without referencing that assembly.
A referenced assembly need not be present at runtime, except when code in that assembly is actually needed, i.e. some other code attempts to call that code.
In general, this means that as long as other assemblies which are referencing your assembly and which don't reference Microsoft.Owin.Security.Cookies also don't call any code in your assembly that would then in turn attempt to call code in Microsoft.Owin.Security.Cookies, that assembly need not be present at runtime.
The tricky part on that second point is that what constitutes "calling code in Microsoft.Owin.Security.Cookies" is not always clear. Typically, as long as you don't access the types in the assembly at all, .NET won't try to execute any code in that assembly. But it's not hard to accidently access the types even when they are not necessarily needed (e.g. in initializers, static or otherwise, code that checks for interface implementations, etc.).
If you really want your clients to be able to use your DLL, which references Microsoft.Owin.Security.Cookies, without necessarily needing that DLL to be present at runtime, you will need to be very careful to ensure you've fully supported that scenario. It is possible to do, but it's also not hard to make a mistake.
(I have to admit, I'm surprised that this useful question hasn't already been addressed on Stack Overflow. Seems like it would have come up before by now. But I was unable to find a duplicate, hence the answer above. If anyone is aware of a duplicate I've overlooked, I welcome any suitable notice of that.)
Let's say I have assemblies in GAC with versions, 1.1.1.5, 1.1.5.1, 1.1.6.2, 1.2.1.1 and 2.1.2.1. My application have a reference of 1.1.3.0 version. Which assembly will be matched at runtime? and what are the actual rules for assembly matching?
If your reference requires a specific version, by default, it will fail on assembly load, as that version doesn't exist.
This can be configured, however, via Assembly Binding Redirection. There are various options of what will happen here, including:
The reference can say that it doesn't care about versioning, in which case the newest is loaded.
You can configure your application in a way that you specify how to redirect the binding.
The assembly in the GAC can be setup with a publisher policy that specifies how to handle this.
Which assembly will be matched at runtime?
None will be matched, your program will bomb.
The documentation for the Version class talks generically about how you pick version numbers. And yes, you normally consider a change in the build number to be a non-breaking change. And a change in the revision to be low risk. Things you consider when you pick an [AssemblyFileVersion].
However, the default CLR policy does not implement this kind of interpretation of the [AssemblyVersion], it insists on an exact match. It is only happy when it find the exact same DLL that you compiled your program with. This is not normally difficult to ensure. You can override this policy and make it weaker, although you should always think twice about that. There is a very long history of well intended minor changes in source code that just did not pan out that well in practice. Something that Microsoft knows too well, having to maintain code that lasts for decades. The default counter-measures against DLL Hell in the CLR are hard as a rock. As they should be. Ratcheting it down up to you.
Can I restrict classes from a specific namespace from referencing classes in another specific namespace? Both namespaces exist in the same .NET assembly.
Example:
namespace LegacyCode
{
class LegacyClass { ... }
}
namespace NewCode
{
class NewClass {...}
}
I do not want classes from 'NewCode' to be able to reference classes in 'LegacyCode'.
Options:
Have different assemblies (makes deployment harder, build takes longer)
Using a tool like NDetect (costs money!)
Does anyone have any other ideas?
Consider marking the classes with the Obsolete attribute. This will cause any code that isn't itself marked as 'Obsolete' to generate a warning during compilation.
Enable 'Treat warnings as errors' setting on the 'Build' tab of the project file to cause this warning to fail compilation with an error instead.
Edit:
Agree that seperate assemblies is a good strategy to facilitate fading out this code. This won't stop people referring to it though. The obsolete attribute makes it clear that this code is, um, obsolete.
Edit #2:
Thanks to Dan Tao for pointing out the overloaded constructor of the Obsolete attribute. This means you can enforce whether usage of a something should be treated as an error or not, without having to enable treat warnings as errors. There is also usefully the option to specify a message instructing the user of a workaround. This message is displayed during compilation in the error/warning.
Document the design, talk to people, review code. Don't try to throw technology at people problems. (The review part can become more effective with tools like NDetect, though.)
If you really need the isolation of design changes, go for separate assemblies: that's the intended design mechanism. But be sure you have a reasonable versioning scheme both for the interface and the implementation.
I think separate assemblies are the only possible solution.
MS uses the System.ObsoleteAttribute attribute to mark obsolete/legacy code. This attribute provides an ctor that creates a compiler error. Though, I'd use this if there are not too many legacy classes.
As others have said, use the obsolete attribute (Even if you have to rename it).
But go one step further. DELETE ANY Legacy method that is NO longer used as soon as possible. This will prevent someone from using it later. You should start to see the Compiler warnings due to the obsolete attributes to drop over time.
You might even make it a daily one hour long test to eliminate as many compiler warnings as you can... Maybe you pitch in to buy the daily winner a beer (or soft drink..;) after work.
I am working on an application that loads plugins at startup from a subdirectory, and currently i am doing this by using reflection to iterate over the types of each assembly and to find public classes implementing the IPluginModule interface.
Since Reflection involves a performance hit, and i expect that there will be several plugins after a while, i wondered if it would be useful to define a custom attribute applied at the assembly level, that could be checked before iterating over the types (possibly about a dozen types in an assembly, including 1 implementor of IPluginModule).
The attribute, if present, could then provide a method to return the needed types or instances, and iterating over the types would then only be a fallback mechanism. Storing the type info in a configuration file is not an option.
Would this improve performance, or does it just not matter compared to the time to actually takes to load the assembly from storage? Also, would this usage be appropriate for an attribute at all?
I will answer your question with a question: Why are you worried about this?
You're worrying about a potential performance hit in a one time operation because there might be several plugins at a later date.
Unless your application startup time is excessively long to a user, I wouldn't waste time thinking about it - there are probably much better things that you can work on to improve your application.
You could also have the plugable types in a configuration, so you know the exact classes instead of looping through all classes. Would have to have some configuration utility for this option...but could possibly get a good increase in performance depending on the number of classes you are looping through.
I believe both of Microsoft's two .net plugin frameworks, the Managed AddIn Framework (MAF) and the Managed Extensibility Framework (MEF) can use either attributes or reflection to discover plugins. So Microsoft seems to feel attributes are appropriate.
I'm not sure what the performance differences are, though.
A good solution is to cache all information about plugins. The first time the application is started it does a full scan of the plugin dlls, and saves the list of types found in a file. The next time the application starts, it loads the information from the file, which will be much faster than scanning all the dlls again. The application can also store a timestamp of each dll, so if it detects a change in a dll it can re-scan it and update the cache.
That's basically the approach followed by the Mono.Addins framework.
I'd have thought that asking an assembly for all the classes that are tagged with an attribute would also use reflection. It would then come down to which is a faster look up in the metadata, interface implementation or attribute marking?
I am wondering if it is possible to use Code Access Security, and a custom permission class (and attribute), without having to register the assembly that the attribute is in, in the GAC.
At the moment, I get a TypeLoadException when the method with my attribute is called, and I can't seem to get around it. Everything i've read seems to imply that you need to use the GAC in order to achieve this.
Does anyone have any insight?
I've tried to acheive the same end-goal with AOP using PostSharp or AspectDNG, but both of those add an addition dependency to my product, which is not ideal.
I would say yes (but cannot be sure without more details of what and how you are doing). We have custom permissions/roles with CAS here and nothing is in the GAC wrt to security. Ultimetly CAS will need to access your assemblies' implementation of IPrincipal. Have you looked at the fusion log to determine where your assemblies are being probed?
Thank you. It seems you simply cannot have your custom attributes be child classes, and you must have only one constructor, which takes on a SecurityAction.