|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Questions and observations about CAS and the StrongNameIdentityPermssionAttribute.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 -- 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!" "John Sheppard" <John.Sheppard@newsgroups.nospam> wrote in message Before digging into your specific questions, just a little warning about news:uEN2HcYrFHA.4072@TK2MSFTNGP09.phx.gbl... > 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. 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. True.> > 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 True.> 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 This would be true if UnrestrictedFunctionB were virtual. Since it's not, > public key contained in keyFileB.snk can override > RestrictedFunctionOverideObject. RestrictedFunctionC but any object > inheriting from RestrictedFunctionOverideObject can override > UnrestrictedFunctionB. it can't be overriden at all. > 4. Only assemblies signed with the private key counterpart of the Not quite. The fields (aka member variables) of the class are not protected > public key contained in keyFileA.snk can instantiate and/or use > ComponentB. RestrictedObjectA. by the link demand. > Now for what I observed: It should.> > 1. This held true. > 2. If I signed ExecutableA with keyFileA.snk or any other key for It behaves as expected for me. Perhaps you've made an error when specifying > that matter and I try to instantiate RestrictrictedObjectInheritance I get > a security exception. Anyone know why this would be? 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 Unless this is a compiler error due to the fact that UnrestrictedFunctionB > exception if I try to override RestrictedFunctionOverideObject. > 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. Show quoteHide quote > > > > 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 > > > -- > 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!" >
Show quote
Hide quote
"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message Calinoin,news:%23SQhehZrFHA.3792@TK2MSFTNGP10.phx.gbl... > "John Sheppard" <John.Sheppard@newsgroups.nospam> wrote in message > news:uEN2HcYrFHA.4072@TK2MSFTNGP09.phx.gbl... >> 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... 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 "John Sheppard" <John.Sheppard@newsgroups.nospam> wrote in message <snip>news:uU6v20ZrFHA.1128@TK2MSFTNGP11.phx.gbl... > Secondly let me pose a question. Is this the official MS answer on I don't work at Microsoft, so no. <g> I haven't seen anything directly > this subject? 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 code can bypass CAS entirely by calling into unmanaged code > fully trusted assemblies can override your demanded criteria. 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 No, it works fine as long the user does not grant unrestricted permissions > 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. 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 Code running with an unrestricted permission grant (full trust) always > 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. 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 Yup, and you always were. In addition to highly privileged code being able > calling private methods I am just SOL. 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. Show quoteHide quote > 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 > 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 Show quoteHide quote > "John Sheppard" <John.Sheppard@newsgroups.nospam> wrote in message > news:uEN2HcYrFHA.4072@TK2MSFTNGP09.phx.gbl... > >> 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 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 >> >> -- >> 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!" 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> Show quoteHide quote "Dominick Baier [DevelopMentor]" <dbaier@pleasepleasenospamdevelop.com> wrote in message news:818143632611127682555232@news.microsoft.com... > 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 > >> "John Sheppard" <John.Sheppard@newsgroups.nospam> wrote in message >> news:uEN2HcYrFHA.4072@TK2MSFTNGP09.phx.gbl... >> >>> 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 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 >>> >>> -- >>> 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!" > > > 
Other interesting topics
Security for a pluggable application
[ANN][X-POST] Goliath.NET Obfuscator... Implementing Kerberos Authentication Limiting exe permissions signcode vs signtool Impossible to set security policy for VSTO Excel? C#.NET app to run on Win 2003 from another Win2003 on the local net? SetOwner problem? Get the user email Securing .NET Assemblies |
|||||||||||||||||||||||
