Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Security / August 2005

Tip: Looking for answers? Try searching our database.

Questions and observations about CAS and the StrongNameIdentityPermssionAttribute.

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
John Sheppard - 30 Aug 2005 18:19 GMT
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.  I apologize upfront for
the long winded nature of this post but I am trying to be clear on my
intent.

           Let put some context to the problem before I start to ask
question.  Application consists of multiple assemblies with the controlling
assembling being an executable.  The following is all pseudo code to
illustrate how things are configured.

ExecutableA.exe is signed with keyFileA.snk

ComponentB.dll is signed with keyFileB.snk

ComponentC.dll is signed with keyfileC.snk

ComponentC has two classes:

namespace ComponentC

{

[StrongNameIdentityPermissionAttribute(SecurityAction. InheritanceDemand,

PublicKey="Public Key of keyFileB.snk"]

public class RestrictrictedObjectInheritance

{

           // constructor here

           public void UnrestrictedFunctionA()

           {}

           [StrongNameIdentityPermissionAttribute(SecurityAction.
LinkDemand,

           PublicKey="Public Key of keyFileA.snk"]

           public virtual void RestrictrictedFunctionB()

           {}

}

public abstract class RestrictedFunctionOverideObject

{

           // constructor here

public void UnrestrictedFunctionB()

           {}

[StrongNameIdentityPermissionAttribute(SecurityAction. InheritanceDemand,

PublicKey="Public Key of keyFileB.snk"]

           public virtual void RestrictedFunctionC()

           {

           }

}

}

Now ComponentB has three classes

namespace ComponentB

{

[StrongNameIdentityPermissionAttribute(SecurityAction. SecurityAction.
LinkDemand,

PublicKey="Public Key of keyFileA.snk"]

           public class RestrictedObjectA

           {

                       public void DoSomeWork()

{

}

           }

public class OverrideRestrictrictedObjectInheritance :
RestrictrictedObjectInheritance

{

           public override void RestrictrictedFunctionB()

{

}

}

public class InheritRestrictedFunctionOverideObject :
RestrictedFunctionOverideObject

{

           public override void RestrictedFunctionC()

{

}

}

}

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.

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.

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.

4.      Only assemblies signed with the private key counterpart of the
public key contained in keyFileA.snk can instantiate and/or use ComponentB.
RestrictedObjectA.

Now for what I observed:

1.      This held true.

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?

3.      This holds true for the first part of the statement but throws an
exception if I try to override RestrictedFunctionOverideObject.
UnrestrictedFunctionB.

4.      This holds true.

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
try to clarify.  The reason for all the convoluted permissions is because
this is a plugin framework and somethings can be overridden in base classes
and some can't and some functions and objects can only be
called/instantiated by the plug in framework while others are completely
unrestricted.

Thanks for any advice,

John

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!"

Nicole Calinoiu - 30 Aug 2005 20:23 GMT
> 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!"

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.