
Signature
Life should NOT be a journey to the grave with the intention of
arriving safely in an attractive and well preserved body, but rather
to skid in sideways, chocolate in one hand, martini in the other, body
thoroughly used up, totally worn out and screaming "WOO HOO what a
ride!"
> Hi Folks,
>
> Hope someone out there can shed some light on this for me. I'm
> having trouble figuring out how to correctly use security attributes, in
> particular StrongNameIdentityPermssionAttribute.
Before digging into your specific questions, just a little warning about
demands for SNIP (StrongNameIdentityPermission) and other identity
permissions... In v. 1.x of the .NET Framework, code with high CAS
privilege can easily spoof or bypass demands for identity permissions. This
means that there are only two scenarios in which SNIP demands like those in
your sample code would be useful:
1. Preventing code with low CAS privilege from using your code either
accidentally or deliberately.
2. Preventing code with high CAS privilege from using your code
accidentally.
In v. 2.0 of the .NET Framework, fully trusted code passes all demands for
any identity permission, regardless of whether the assembly in question
actually has matching evidence. This means that identity permission demands
will shortly become useless for scenario #2 above. Given this, you may want
to give some consideration to whether you really want to pursue the SNIP
demand approach...
<snip>
> Okay now for what I expect.
>
> 1. Only assemblies signed with the private key counterpart of the
> public key contained in keyFileB.snk can inherit from
> RestrictrictedObjectInheritance.
True.
> 2. If RestrictrictedObjectInheritance is instantiated directly only
> assemblies that are signed with the counterpart of the public key
> contained in keyFileA.snk can invoke RestrictrictedObjectInheritance.
> RestrictrictedFunctionB.
True.
> 3. Only assemblies signed with the private key counterpart of the
> public key contained in keyFileB.snk can override
> RestrictedFunctionOverideObject. RestrictedFunctionC but any object
> inheriting from RestrictedFunctionOverideObject can override
> UnrestrictedFunctionB.
This would be true if UnrestrictedFunctionB were virtual. Since it's not,
it can't be overriden at all.
> 4. Only assemblies signed with the private key counterpart of the
> public key contained in keyFileA.snk can instantiate and/or use
> ComponentB. RestrictedObjectA.
Not quite. The fields (aka member variables) of the class are not protected
by the link demand.
> Now for what I observed:
>
> 1. This held true.
It should.
> 2. If I signed ExecutableA with keyFileA.snk or any other key for
> that matter and I try to instantiate RestrictrictedObjectInheritance I get
> a security exception. Anyone know why this would be?
It behaves as expected for me. Perhaps you've made an error when specifying
the public key string for the A key in the link demand attribute?
> 3. This holds true for the first part of the statement but throws an
> exception if I try to override RestrictedFunctionOverideObject.
> UnrestrictedFunctionB.
Unless this is a compiler error due to the fact that UnrestrictedFunctionB
is not virtual, could you please provide the exception details (as returned
by its ToString method)?
> 4. This holds true.
You should try testing access to fields from an assembly that doesn't pass
the link demand.
> Can anyone give me any insight as to why items 2 & 3 would be failing like
> they are? If I have not provided enough information let me know and I'll
[quoted text clipped - 7 lines]
>
> John
John Sheppard - 30 Aug 2005 20:58 GMT
>> Hi Folks,
>>
[quoted text clipped - 20 lines]
> you may want to give some consideration to whether you really want to
> pursue the SNIP demand approach...
Calinoin,
First off let me say thank you very much for your speedy reply. I will
go back and review the points that you made and thanks for catching my
(psuedo)coding mistake. :D
Secondly let me pose a question. Is this the official MS answer on this
subject? Because if it is that sucks. Not only does it suck it seems very
illogical. Why have CAS then if a fully trusted assemblies can override
your demanded criteria. Think about this. Say I have an object library
assembly whose classes I have decorated to demand that inheritors and or
callers be signed with a certain strongnamekey. This works fine as long as
I do not fully trust the implementation / calling code. My object library
is protected in this scenerio. Or lets say I want to have multiple levels
of access to my API based upon the SNK of my callee/inheritor. Again as
long as I do not fully trust the calling/implementing assembly all is fine.
Now regardless of what the object library developer wishes are on this
subject I developer B want to use he object library so I fully trust the
code calling his stuff and viola I can now use it. This has ramifications
for not only SNIP but reflection and I presume FileIO as well. So if I don't
want somebody dynamically reflecting over my code and calling private
methods I am just SOL. This is scary and from my perspective just plain
wrong. So before I drive out to Redmond and ask Bill why please tell me I'm
wrong.
Again thanks for the answers but now I have to go take my blood preasure
medication.
John
Nicole Calinoiu - 30 Aug 2005 21:43 GMT
<snip>
> Secondly let me pose a question. Is this the official MS answer on
> this subject?
I don't work at Microsoft, so no. <g> I haven't seen anything directly
relevant in the "official" docs yet. The most on-point statement that I
know of from a Microsoft employee is on Eugene Bobukh's blog at
http://blogs.msdn.com/eugene_bobukh/archive/2005/05/06/415217.aspx.
> Because if it is that sucks.
I actually tend to agree (at least partially), so don't shoot the messenger.
<g>
> Not only does it suck it seems very illogical. Why have CAS then if a
> fully trusted assemblies can override your demanded criteria.
Fully trusted code can bypass CAS entirely by calling into unmanaged code
directly, so the ability to bypass any given permission isn't considered a
security hole.
> Think about this. Say I have an object library assembly whose classes I
> have decorated to demand that inheritors and or callers be signed with a
> certain strongnamekey. This works fine as long as I do not fully trust
> the implementation / calling code.
No, it works fine as long the user does not grant unrestricted permissions
to the calling code. You might want to keep in mind that CAS is meant to
prevent the user, not the developer or his code.
> My object library is protected in this scenerio. Or lets say I want to
> have multiple levels of access to my API based upon the SNK of my
[quoted text clipped - 4 lines]
> viola I can now use it. This has ramifications for not only SNIP but
> reflection and I presume FileIO as well.
Code running with an unrestricted permission grant (full trust) always
passed all demands for ReflectionPermission and FileIOPermission. The only
demands it didn't automatically pass were those for identity permissions
that corresponded to evidence it did not have. In v. 2.0, those have been
added to the pass list.
> So if I don't want somebody dynamically reflecting over my code and
> calling private methods I am just SOL.
Yup, and you always were. In addition to highly privileged code being able
to deliberately bypass permission verifications, the user could always
disable CAS entirely if he deliberately wanted to enable bypassing of your
protections.
> This is scary and from my perspective just plain wrong.
Only if you're counting on CAS to protect your code from callers that you
consider "undesirable" even if your users don't. Granted, there's plenty of
documentation out there (including quite a bit that came directly from
Microsoft or was sponsored by Microsoft) that suggests that CAS can do this.
Unfortunately, it's pretty much all wrong even with respect to version 1.x.
> So before I drive out to Redmond and ask Bill why please tell me I'm
> wrong.
[quoted text clipped - 3 lines]
>
> John
Dominick Baier [DevelopMentor] - 31 Aug 2005 19:18 GMT
Hello Nicole Calinoiu" calinoiu REMOVETHIS AT gmail DOT com,
LOL - i like SNIP - nearly as much as SUCS (SuppressUnmanagedCodeSecurity)
---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com
>> Hi Folks,
>>
[quoted text clipped - 100 lines]
>> thoroughly used up, totally worn out and screaming "WOO HOO what a
>> ride!"
Nicole Calinoiu - 31 Aug 2005 19:49 GMT
Shouldn't that be SUCSA (with SNIP, one can justify not including the
trailing "A" since it's not always an attribute), which may or may not be
more "interesting" depending on which language one is speaking... <g>
> Hello Nicole Calinoiu" calinoiu REMOVETHIS AT gmail DOT com,
>
[quoted text clipped - 108 lines]
>>> thoroughly used up, totally worn out and screaming "WOO HOO what a
>>> ride!"