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
