One thing that they don’t mention, which most people might think is obvious, is that StrongNameIdentityPermission means nothing when calling the managed code from unmanaged code. Since umanaged code can’t be signed (at least not in the same meaning as managed code can) it isn’t too surprising. What is a bit surprising might be that the call into the assembly is permitted. I was hoping that the magic in the .Net framework would put a stop to it all. No
such luck!
This means that someone who wants to circumvent the access control doesn’t have to bother with delayed signing and extracting the public key from the ‘protected’ assembly. It also means that the ‘attacker’ doesn’t have to be able to write to the GAC, only read from it (something all users have permission to do). Writing unmanaged code that calls managed code isn’t too difficult.
I’ve been looking into .Net the last few days. Especially the interplay between managed and unmanaged code relating to COM (COM+) components. The most amazing thing is how
much thing the framework will do for you implicitly. E.g. there is no visible
difference in the source between instantiating a COM component and
instantiating an object of a class. From a run-time perspective there is a
huge difference of course, but the source for the managed code looks the same.
No use of CoCreateInstance() anywhere!
I can clearly see how this is an appealing feature from the coder’s point of
view. It means the deployment can be decided very late. You wan’t class A to
be a COM component? Sure, why not? All it takes is adding an attribute to a
class, that can be done at the very late in development. In short the
COM-isation doesn’t have to happen until the very last step. Decision time is
pushed as far back as possible. Cool! Right?
Explicitness does have a lot going for itself:
It makes the developer think about what he’s doing.
It also forces some things to come up to the surface early on.
In the example with managed COM components the thing that doesn’t surface
until it’s too late is access control. When pushing the deployment decisions
to the end of a project there is little incentive to put access control in the
code during development. By the time it’s clear where the access control is
needed it’s too late to put it in, unless you want to blow your dead line.
So, in the end the lack of explicitness will require the developer to know
more about the framework and how it works… the irony is that this is what
the magic was put there to prevent.
![[Digg]](http://therning.org/magnus/wp-content/plugins/bookmarkify/digg.png)
![[Reddit]](http://therning.org/magnus/wp-content/plugins/bookmarkify/reddit.png)
