A possible simplification exists, I think. If the creation of Identity does not rely on the instance of the PLUGIN ... The SECURITY object can create an Identity before it creates the PLUGIN, and then passes the Identity in to the PLUGIN constructor (it is only the SECURITY object that creates PLUGINs right?). The PLUGIN only has a 'getter' for it's Identity. The Identity is still randomly generated and associated with one PLUGIN, making it hard for anybody to fake.
It seems a lot simpler - I'm guessing I may have missed something. Mark -----Original Message----- From: Janis Braslins [mailto:[EMAIL PROTECTED] Sent: 22 August 2003 14:04 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Design Puzzle Once again thank you to everyone who replied! I think I figured it out. I like the cookie approach. I've extended on it a little: 1) Since value of read-only Identity property will be passed to the SECURITY object to determine the callers role and perhaps a callback reference if necessary, Identity property must be protected so it's not accessible by other PLUGINS. If some malicious PLUGIN read it's own identity and informs other PLUGINS of it .. it would not be able to obtain any privileges it does not have, just delegate it's privileges to others. 2) In order for SECURITY object to be able to set the identity of the new instance of a PLUGIN, a SetIdentity method will be implemented. Now the tricky part ... since PLUGINS are designed to interact. We want to prevent them from being able to modify other PLUGIN's identities. It's imperative that we prevent malicious PLUGINS from setting a bogus identity on a victim PLUGIN which would result in a loss of privileges for the victim. So somehow we must ensure that only SECURITY object is capable of performing SetIdentity calls. The only solution I have for that so far goes something like this: 1) Both SetIdentity method and Identity property are defined and implemented in the base class inherited by all PLUGINS. 2) Identity structure contains two tokens, one used to identify PLUGIN when calling SECURITY (PluginIdentity), and another to verify identity of the SECURITY object when calling SetIdentity on the PLUGIN (SecurityIdentity). 3) Constructor of the BaseClass assigns a default constant Identity to the PLUGIN. That constant Identity is defined in both the BaseClass and SECURITY class. 4) SetIdentity method requires two Identity structures to be passed: CurrentIdentity and NewIdentity. Only when CurrentIdentity argument matches PLUGIN's current Identity, the operation is allowed. 5) Immediately after PLUGIN instance creation, SECURITY object performs SetIdentity call on the PLUGIN passing the known constant Identity as CurrentIdentity, and a brand new Identity for the PLUGIN which contains a new SecurityIdentity token. SECURITY object keeps track of Identities it issues to each plugin in case it needs to modify PLUGIN's identity in the future. I think this model would allow for SECURITY object only to change PLUGINS identity token (as many times as necessary). We also could simply opt out for SetIdentity method to use a Boolean flag that would prevent that method from being invoked more than once, so that nobody can modify PLUGIN's identity after initial invocation by SECURITY object. That would remove the need for second (SecurityIdentity) token. Thanx! Please feel free to comment. On Thu, 21 Aug 2003 16:28:32 -0400, J. Merrill <[EMAIL PROTECTED]> wrote: >SECURITY is a singleton, right? (Or do you have one per PLUGIN type? Not sure it matters.) > >I think the answer lies in giving each plugin a "cookie" that it has to use in order to make calls; if the cookie values can't be faked, I think you're safe. Details: > >SECURITY is (or should be) responsible for creating the PLUGIN instances. Each PLUGIN class has an Identity property (a read-only string, but the read-only is not important to the security [as it's bogus]). When SECURITY creates a PLUGIN, it assigns an essentially arbitrary (unpredictable) value to the Identity property. The methods of SECURITY that PLUGINs can call each require a valid Identity value to be passed in. > >Information about the PLUGINs is recorded in a SECURITY-owned HashTable with the Identity values as the key. The corresponding objects stored in the HashTable include a field that holds a reference to the PLUGIN that has the matching Identity. > >If a call to SECURITY is made that has a not-present Identity value, someone is trying to break security (or has buggy code). If more than N bad calls are made, any PLUGIN of that type is shut down when it next makes a call. (Each PLUGIN-callable SECURITY method must have a result value that indicates "you are no longer a valid instance; good night.") > >If you use a cryptographically strong mechanism to generate the Identity values, you're pretty safe. One semi-flaw is that a PLUGIN that's trying to break in (by passing a bunch of fake Identity values, one of which it hopes will identify another active PLUGIN) could cause a Denial Of Service if you implement the "shut down all PLUGINs of that type" protection mechanism above. But if the source code for the PLUGIN is in your hands, a human being could figure out what's going on -- it's not just anyone that can ask for a new PLUGIN type to be created, right? That is, you would know who wanted to build a PLUGIN that was being naughty and could take appropriate non-computer-related action. > >Good luck. > =================================== This list is hosted by DevelopMentorŪ http://www.develop.com NEW! ASP.NET courses you may be interested in: 2 Days of ASP.NET, 29 Sept 2003, in Redmond http://www.develop.com/courses/2daspdotnet Guerrilla ASP.NET, 13 Oct 2003, in Boston http://www.develop.com/courses/gaspdotnet View archives and manage your subscription(s) at http://discuss.develop.com ************************************************************************ This email (including any attachments to it) is confidential, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this email in error, please advise us immediately and delete it. You are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or attachments.We exclude any liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided in this email or its attachments, unless that information is subsequently confirmed in writing. If this email contains an offer, that should be considered as an invitation to treat. ************************************************************************* ================================================================== =================================== This list is hosted by DevelopMentorŪ http://www.develop.com NEW! ASP.NET courses you may be interested in: 2 Days of ASP.NET, 29 Sept 2003, in Redmond http://www.develop.com/courses/2daspdotnet Guerrilla ASP.NET, 13 Oct 2003, in Boston http://www.develop.com/courses/gaspdotnet View archives and manage your subscription(s) at http://discuss.develop.com
