Issue 2639: Firewall POA Policy does not control access (firewall-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: In orbos/98-07-03 4.9 it says "However, it is desirable to provide a portable means by which the object implementor can decide whether an object could be accessible through a firewall. The following POA policy is defined for this purpose:" but this policy can at most control what components are included in references created by the POA. Since the references do not have any mechanism to defend against forgery, exclusion of a FirewallMechanism component does not prevent access through a firewall. If an attacker obtains some other reference with the FirewallMechanism component(s), it can convert a reference created under NO_EXPORT into the reference that would have been created under EXPORT. The description of the policy needs to be changed to make it clear that the policy does not imply any access control enforcement. The ability of an attacker to forge references, either by combining parts of other references, or otherwise, should be explicitly stated as a security issue that must be addressed by means outside this specification. Resolution: Revised Text: Actions taken: May 6, 1999: received issue Discussion: End of Annotations:===== Date: Thu, 06 May 1999 12:08:15 +0100 From: Owen Rees To: OMG Issues , OMG Firewall RTF Subject: Firewall POA Policy does not control access Originator-Info: login-id=ore; server=ews.hpl.hp.com Content-Disposition: inline In orbos/98-07-03 4.9 it says "However, it is desirable to provide a portable means by which the object implementor can decide whether an object could be accessible through a firewall. The following POA policy is defined for this purpose:" but this policy can at most control what components are included in references created by the POA. Since the references do not have any mechanism to defend against forgery, exclusion of a FirewallMechanism component does not prevent access through a firewall. If an attacker obtains some other reference with the FirewallMechanism component(s), it can convert a reference created under NO_EXPORT into the reference that would have been created under EXPORT. The description of the policy needs to be changed to make it clear that the policy does not imply any access control enforcement. The ability of an attacker to forge references, either by combining parts of other references, or otherwise, should be explicitly stated as a security issue that must be addressed by means outside this specification. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 From: Paul Kyzivat To: "Firewall RTF (E-mail)" Subject: RE: Firewall policies Date: Tue, 7 Dec 1999 16:57:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: abPe9 Yes orb level would establish the default. The poa policy affects all > objects associated with that POA. > In the current policy model of 2.3.1 there is no way on the > server side to associate policies to individual objects. I thought there was a way, on the client side, to combine an object with a policy, yielding a "new" object. (Actually only a new client side representation of the object.) Anything that can be done to an object on the client side should be applicable to objects by a server as well. > > > > > Next question - suppose I have one poa with InvokeMode = > NORMALONLY, and > > another with InvokeMode = BIDIRONLY. Does this mean that the orb > > *must* have > > two addresses, so that objects with NORMALONLY can't be > invoked over a > > connection enabled for bidir? (The alternative is that this > > policy could be > > omitted, or it could cause something to be added to the > object reference > > encoding the rule it states.) It will take a lot of convincing > > before I will > > go along with requiring the server to use two addresses in > this case. > > first I don't think we want to go down the route of adding > bidir components to IORs. I didn't think so. :-) > You would need two addresses though - since although > this policy indicates whether you can put the objects address > in service context if two > objects share the same address and bothe have different modes > the address > sent in the service context could be used to send requests to > both objects. I don't find this appealing. To keep things consistent, I think it would be necessary to have a separate address for each poa carrying this policy. Otherwise, there are implicit interactions between poas. I also see very little value in restricting at this level. What does it accomplish? I think it would be better to make this an ORB level policy. The harder problem is figuring out how to establish an orb level policy before the root POA is created, since there is no overt creation of the root poa. > I guess the only way around this is to include objects keys > in the listen point service context, biut that would be quite a > major change. Whats wrong with having two addresses? We like to permit our users to specify the address their server runs on. Having two makes it more complex to configure servers. And extra addresses means having one more thing to listen to. It would be different if there was some obvious benefit to this. > > > > For ConnectionMode - this seems to imply something about > the semantics and > > granularity of connections, without being clear what that is. > > Does this mean > > that orb in general needs to be able to maintain two > connections to each > > endpoint - one on which bidir is enabled and another where > it is not, and > > that each object will be associated with the one of these > that matches the > > policy it has? > > Of course the whole notion of connection is vague in corba:-( > To be honest i'm not sure what this means looking at this > again - we just > need a way to signify when to send the service context and on what > connections. If i say connection mode = normal and then use a > bidir one this > make no difference to the invocation. > I need to rethink this one. I agree. To clarify my role here: up to now I have been taking a passive role, asking for clarification, on the assumption that this was well understood but not well explained. It now seems that is is a bad assumption. If this indeed requires changes rather than just clarifications, then I will take a more active role. From: Paul Kyzivat To: "Firewall RTF (E-mail)" Subject: RE: Firewall policies Date: Tue, 7 Dec 1999 16:52:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Fejd9foHe9@#[!!9n:e9 Martin had sent me an earlier copy of his thoughts on bidir policies, and I replied before that message was posted to the ftf. Here are those comments of mine, together with Martin's replies to me. In a separate message I will send my subsequent reply. Paul > -----Original Message----- > From: Martin Chapman [mailto:mchapman@iona.com] > Sent: Tuesday, December 07, 1999 6:17 AM > To: Paul Kyzivat > Subject: RE: Firewall policies > > > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:paulk@roguewave.com] > > Sent: 03 December 1999 18:47 > > To: 'mchapman@iona.com' > > Cc: 'Paul Kyzivat' > > Subject: RE: Firewall policies > > > > > > The notion of the three levels of control seems reasonable. > > The scope of application seems a bit fuzzy: > > > > For InvokeMode you say the scope is ORB or POA. Does attaching it > > to the orb > > merely establish a default for all POAs (including the root poa) > > that can be > > overridden for particular POAs (except of course for the root poa > > that can't > > be overridden)? And then, since you say it really has to do with a > > particular object, do you mean that the setting for a poa > affects each > > object created by that poa? If so, would it not also make > sense to permit > > the policy to be attached to an individual object as well? > > Yes orb level would establish the default. The poa policy affects > all > objects associated with that POA. > In the current policy model of 2.3.1 there is no way on the > server side to > associate policies to > individual objects. > > > > > Next question - suppose I have one poa with InvokeMode = > NORMALONLY, and > > another with InvokeMode = BIDIRONLY. Does this mean that the orb > > *must* have > > two addresses, so that objects with NORMALONLY can't be > invoked over a > > connection enabled for bidir? (The alternative is that this > > policy could be > > omitted, or it could cause something to be added to the > object reference > > encoding the rule it states.) It will take a lot of convincing > > before I will > > go along with requiring the server to use two addresses in > this case. > > first I don't think we want to go down the route of adding > bidir components > to IORs. You would need two addresses though - since although > this policy > indicates whether you can put the objects address in service > context if two > objects share the same address and bothe have different modes > the address > sent in the service context could be used to send requests to > both objects. > I guess the only way around this is to include objects keys > in the listen > point service context, biut that would be quite a major > change. Whats wrong > with having two addresses? > > > > For ConnectionMode - this seems to imply something about > the semantics and > > granularity of connections, without being clear what that is. > > Does this mean > > that orb in general needs to be able to maintain two > connections to each > > endpoint - one on which bidir is enabled and another where > it is not, and > > that each object will be associated with the one of these > that matches the > > policy it has? > > Of course the whole notion of connection is vague in corba:-( > To be honest i'm not sure what this means looking at this > again - we just > need a way to signify when to send the service context and on what > connections. If i say connection mode = normal and then use a > bidir one this > make no difference to the invocation. > I need to rethink this one. > > > > > For reverseInvokeMode - I can understand this one at orb > and thread scope. > > But what does this mean at object scope? Is this a policy I would > > attach to > > a received object reference? With that clarification I think this > > policy is > > ok. > Exactly - given a recieved IOR you want to overide the orb and > thread > policy. > > > > > In any case, I think you should post this to the FTF for > wider commenting. > > (Maybe you did - I haven't checked that mail recently because I > > am very busy > > now.) > > Will do > > > > > Paul > > > > > > > -----Original Message----- > > > From: Martin Chapman [mailto:mchapman@iona.com] > > > Sent: Friday, December 03, 1999 11:24 AM > > > To: Paul Kyzivat > > > Subject: Firewall policies > > > > > > > > > > > > > > > Paul, > > > I thought I'd run this suggestion past you before I try an > > > elaborate further > > > and circulate to a wider audience. The basis is three > > > policies - one to > > > indicate that an object may be invoked using bidir (i.e. its > > > address may be > > > included in a bidir service context), one to indicate that a > > > connection > > > could be used bi-directionally (i.e. bidir service context is > > > permitted to > > > be transmitted), and one policy to say whether to actually > > > use the bi-dir > > > connection or not. > > > > > > > > > > > > the first would look something like: (ignore style guide > > > issues at this > > > stage) > > > > > > enum usemode { NORMALONLY, BIDIRONLY, EITHER} > > > > > > interface InvokeMode: CORBA::Policy { > > > readonly attribute usemode the_mode; > > > }; > > > > > > Scope - ORB, POA - affects what addresses could be put in a > > > bi-dir service > > > context. > > > NORMALONLY means object can only be invoked using standard GIOP > > > BIDIRONLY means object can only be invoked on the "reverse" > > > of a connection > > > (e.g. for browsers) > > > EITHER means the bleeding obvious!!! > > > > > > The second, something like: > > > > > > enum connmode {NORMAL, BIDIR} > > > > > > interface ConnectionMode: CORBA::Policy { > > > readonly attribute connmode the_mode; > > > }; > > > > > > Scope - ORB, thread, object - affects whether the bidir > > > service context > > > could be transmitted on a connection or not > > > NORMAL means open/use standard GIOP connections (bidir > > > service context never > > > sent on connection) > > > BIDIR means open/use a bidir connection (i.e. bidir service > > > context may be > > > sent over such a connection, which may contain listen point > > > info for objects > > > created with an invokemode of bidironly or either ) > > > > > > The third policy, something like: > > > > > > interface reverseInvokeMode{ > > > readonly attribute usemode the_mode; > > > }; > > > Scope - ORB, thread, object - affects whether you can invoke > > > an object using > > > bi-dir or not > > > NORMAL Means do not use bidir to talk to "client" side > object(s) > > > BIDIRONLY means only use bidir to talk to the "client" > side object(s) > > > EITHER same as before. > > > > > > Is this in the ballpark? > > > > > > Martin. > > > > > > Reply-To: From: "Martin Chapman" To: "Paul Kyzivat" , "Firewall RTF (E-mail)" Subject: RE: Firewall policies Date: Wed, 8 Dec 1999 16:30:41 -0000 Message-ID: <000e01bf4199$919499e0$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA9140214@bos1.noblenet.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ZQAe9ZJ0e9>Z!e9]I2e9 > -----Original Message----- > From: Paul Kyzivat [mailto:paulk@roguewave.com] > Sent: 07 December 1999 21:57 > To: Firewall RTF (E-mail) > Subject: RE: Firewall policies > > > > Yes orb level would establish the default. The poa policy affects > all > > objects associated with that POA. > > In the current policy model of 2.3.1 there is no way on the > > server side to associate policies to individual objects. > > I thought there was a way, on the client side, to combine an object > with a > policy, yielding a "new" object. (Actually only a new client side > representation of the object.) Anything that can be done to an > object on the > client side should be applicable to objects by a server as well. On the client side you can override policies and effectively create a new IOR (since IORs are immutable). The only policies you can override are those dealing with how you interect with the object. This is not possible or appropriate to do on the server side - if you want to change policies you recreate an object on a different poa. > > > > > > > > > Next question - suppose I have one poa with InvokeMode = > > NORMALONLY, and > > > another with InvokeMode = BIDIRONLY. Does this mean that the orb > > > *must* have > > > two addresses, so that objects with NORMALONLY can't be > > invoked over a > > > connection enabled for bidir? (The alternative is that this > > > policy could be > > > omitted, or it could cause something to be added to the > > object reference > > > encoding the rule it states.) It will take a lot of convincing > > > before I will > > > go along with requiring the server to use two addresses in > > this case. > > > > first I don't think we want to go down the route of adding > > bidir components to IORs. > > I didn't think so. :-) > > > You would need two addresses though - since although > > this policy indicates whether you can put the objects address > > in service context if two > > objects share the same address and bothe have different modes > > the address > > sent in the service context could be used to send requests to > > both objects. > > I don't find this appealing. > > To keep things consistent, I think it would be necessary to have > a separate > address for each poa carrying this policy. Otherwise, there are > implicit > interactions between poas. This is certainly the implication as I see it. > > I also see very little value in restricting at this level. What does > it > accomplish? I think it would be better to make this an ORB level > policy. If you want to divide you space into those objects that could be bidirectional and those that aren't you still need two addresses. Making it orb only means you have to expose users to addresses - not all products may like this. > > The harder problem is figuring out how to establish an orb level > policy > before the root POA is created, since there is no overt creation > of the root > poa. This is one reason we specified a default policy value in the first place. > > > > I guess the only way around this is to include objects keys > > in the listen point service context, biut that would be quite a > > major change. Whats wrong with having two addresses? > > We like to permit our users to specify the address their server runs on. > Having two makes it more complex to configure servers. And extra addresses > means having one more thing to listen to. It would be different > if there was > some obvious benefit to this. You don't have to (but you can) listen to addresses that are used for bidir only. > > > > > > > For ConnectionMode - this seems to imply something about > > the semantics and > > > granularity of connections, without being clear what that is. > > > Does this mean > > > that orb in general needs to be able to maintain two > > connections to each > > > endpoint - one on which bidir is enabled and another where > > it is not, and > > > that each object will be associated with the one of these > > that matches the > > > policy it has? > > > > Of course the whole notion of connection is vague in corba:-( > > To be honest i'm not sure what this means looking at this > > again - we just > > need a way to signify when to send the service context and on what > > connections. If i say connection mode = normal and then use a > > bidir one this > > make no difference to the invocation. > > I need to rethink this one. > > I agree. I've been rethinking this one, and I have come to the conclusion that ORB, object and thread are not the correct scopes. In fact we don't have anything that is the correct scope. I think the portable interceptors may have a way round this one, but until that gets adopted we can't use it. I would propose that leave this type of policy as an implementation issue for now. > > To clarify my role here: up to now I have been taking a passive > role, asking > for clarification, on the assumption that this was well understood > but not > well explained. It now seems that is is a bad assumption. If this > indeed > requires changes rather than just clarifications, then I will take a > more > active role. Any suggestions to progress this issue in a timely manner are welcome. martin. From: Paul Kyzivat To: "'mchapman@iona.com'" , Paul Kyzivat , "Firewall RTF (E-mail)" Subject: RE: Firewall policies Date: Thu, 9 Dec 1999 09:03:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: NR From: Martin Chapman [mailto:mchapman@iona.com] ... > > I thought there was a way, on the client side, to combine > an object with a > > policy, yielding a "new" object. (Actually only a new client side > > representation of the object.) Anything that can be done to an > > object on the > > client side should be applicable to objects by a server as well. > > On the client side you can override policies and effectively > create a new > IOR (since IORs are immutable). > The only policies you can override are those dealing with how > you interect > with the object. This is not possible or appropriate to do on > the server side - if you want to change policies you recreate an > object on a different poa. I don't think it is all that clear when it is possible or appropriate to override the policies on an object. It certainly seems like additional uses of this "feature" should be open to consideration. It is true that a server writer has the option of setting policies on the POA, which a client does not. But that may not be the "right" granularity. I think this should probably be determined on a policy-by-policy basis. > > > You would need two addresses though - since although > > > this policy indicates whether you can put the objects address > > > in service context if two > > > objects share the same address and bothe have different modes > > > the address > > > sent in the service context could be used to send requests to > > > both objects. > > > > I don't find this appealing. > > > > To keep things consistent, I think it would be necessary to have > > a separate > > address for each poa carrying this policy. Otherwise, there > are implicit > > interactions between poas. > > This is certainly the implication as I see it. This is insane. We are talking about a program that wants to accept certain requests via bidir giop, and certain other requests via normal inbound connections. (I can't imagine why this would be.) In addition to the listening port on which it expects to receive requests, you are suggesting that it must have another port assigned to it solely so that it can use the address in iors that are to be used bidirectionally. It will expect not to receive connection requests on this address, but needs to be prepared to do so (in case someone who doesn't support bidir wants to contact it.) > If you want to divide you space into those objects that could be > bidirectional and those that aren't you still need two > addresses. I don't want to divide it into two spaces. You are suggesting that, and I don't see why. Perhaps you can explain why that is a useful thing to do. > Making it orb only means you have to expose users to addresses - not > all products may like this. Why does this necessarily expose the user to addresses? Surely it could be possible to set the policy on the orb without explicitly specifying an address. The orb can get its address however it wants. It will however need to have an address that remains unchanged for the lifetime of the IORs it publishes. As long as its IORs are transient, that can be the same as the life of the process itself; this should be the normal use case. > You don't have to (but you can) listen to addresses that are > used for bidir only. You don't need to listen to them. But you (or somebody) needs to at least allocate them. Otherwise, the address may inadvertently get picked up and used by another server. That could cause mass confusion for anybody attempting to use your IORs without. > > > > For ConnectionMode - this seems to imply something about > > > the semantics and > > > > granularity of connections, without being clear what that is. > > > > Does this mean > > > > that orb in general needs to be able to maintain two > > > connections to each > > > > endpoint - one on which bidir is enabled and another where > > > it is not, and > > > > that each object will be associated with the one of these > > > that matches the > > > > policy it has? > > > > > > Of course the whole notion of connection is vague in corba:-( > > > To be honest i'm not sure what this means looking at this > > > again - we just > > > need a way to signify when to send the service context and on > what > > > connections. If i say connection mode = normal and then use a > > > bidir one this > > > make no difference to the invocation. > > > I need to rethink this one. > > > > I agree. > > > I've been rethinking this one, and I have come to the > conclusion that ORB, > object and thread are not the correct scopes. In fact we > don't have anything > that is the correct scope. I think the portable interceptors > may have a way > round this one, but until that gets adopted we can't use it. > I would propose > that leave this type of policy as an implementation issue for now. I don't think we should close the issue on that basis. Perhaps it will take some time to find a suitable solution. If so, orbs are free to implement whatever they want in the meantime. But until this is resolved users will have to realize that they are dependent on proprietary mechanisms. Reply-To: From: "Martin Chapman" To: "Paul Kyzivat" , "Firewall RTF (E-mail)" Subject: RE: Firewall policies Date: Thu, 9 Dec 1999 16:57:27 -0000 Message-ID: <000201bf4266$78cc1000$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA9140227@bos1.noblenet.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: j68e9@iW!!g[2!!C/^d9 > -----Original Message----- > From: Paul Kyzivat [mailto:paulk@roguewave.com] > Sent: 09 December 1999 14:03 > To: 'mchapman@iona.com'; Paul Kyzivat; Firewall RTF (E-mail) > Subject: RE: Firewall policies > > > > From: Martin Chapman [mailto:mchapman@iona.com] > ... > > > I thought there was a way, on the client side, to combine > > an object with a > > > policy, yielding a "new" object. (Actually only a new client > side > > > representation of the object.) Anything that can be done to an > > > object on the > > > client side should be applicable to objects by a server as well. > > > > On the client side you can override policies and effectively > > create a new > > IOR (since IORs are immutable). > > The only policies you can override are those dealing with how > > you interect > > with the object. This is not possible or appropriate to do on > > the server side - if you want to change policies you recreate an > > object on a different poa. > > I don't think it is all that clear when it is possible or > appropriate to > override the policies on an object. It certainly seems like > additional uses > of this "feature" should be open to consideration. I don;t think this RTF is the appropriate place to do this. > > It is true that a server writer has the option of setting policies > on the > POA, which a client does not. But that may not be the "right" > granularity. I > think this should probably be determined on a policy-by-policy > basis. Sure you can document what scope a policy applies to. > > > > > You would need two addresses though - since although > > > > this policy indicates whether you can put the objects address > > > > in service context if two > > > > objects share the same address and bothe have different modes > > > > the address > > > > sent in the service context could be used to send requests to > > > > both objects. > > > > > > I don't find this appealing. > > > > > > To keep things consistent, I think it would be necessary to have > > > a separate > > > address for each poa carrying this policy. Otherwise, there > > are implicit > > > interactions between poas. > > > > This is certainly the implication as I see it. > > This is insane. > > We are talking about a program that wants to accept certain requests > via > bidir giop, and certain other requests via normal inbound > connections. (I > can't imagine why this would be.) In addition to the listening > port on which > it expects to receive requests, you are suggesting that it must > have another > port assigned to it solely so that it can use the address in iors > that are > to be used bidirectionally. It will expect not to receive connection > requests on this address, but needs to be prepared to do so (in > case someone > who doesn't support bidir wants to contact it.) lets take a step back and look at the three use models: 1) In some environments (browsers or other) it is not possible to accept incomming connections. Therefore for a callback object your only choice is use bidir. So you allocate a host and port number, use this in the ior and also send it over in the bidir service context. The client doesn't have to (or may not be able to) listen on this port in the case of bidir only . 2) for whatever reason (security considerations etc) you don't want any of your objects invoked bi-directionally. here you stick to normal giop rules, lisen on a port and wait for incomming connections. 3) for whetever reason, you may want some of your objects to be invoked bidir only and some normal only. We have to have a mechanism to distinguish the two - the only way to do this in the current spec is through the listen point data (a sequence of host/port pairs) so in this mixed mode only you have to have two distinct ports - the port for the normal only object shoudl not be sent in th bidir service context. > > > If you want to divide you space into those objects that could be > > bidirectional and those that aren't you still need two > > addresses. > > I don't want to divide it into two spaces. You are suggesting that, > and I > don't see why. Perhaps you can explain why that is a useful thing to > do. The current spec worked on the assumption that you may want to have some objects that can be invoked on the reverse of a connection and some that can only be invoked using the normal giop model. > > > Making it orb only means you have to expose users to addresses - not > > all products may like this. > > Why does this necessarily expose the user to addresses? > Surely it could be possible to set the policy on the orb without > explicitly > specifying an address. The orb can get its address > however it wants. It will however need to have an address that remains > unchanged for the lifetime of the IORs it publishes. As long as > its IORs are > transient, that can be the same as the life of the process itself; this > should be the normal use case. > > > You don't have to (but you can) listen to addresses that are > > used for bidir only. > > You don't need to listen to them. But you (or somebody) needs to at least > allocate them. Otherwise, the address may inadvertently get picked up and > used by another server. That could cause mass confusion for anybody > attempting to use your IORs without. true in most environments (i don't think its possible in browser environments.) > > > > > > For ConnectionMode - this seems to imply something about > > > > the semantics and > > > > > granularity of connections, without being clear what that > is. > > > > > Does this mean > > > > > that orb in general needs to be able to maintain two > > > > connections to each > > > > > endpoint - one on which bidir is enabled and another where > > > > it is not, and > > > > > that each object will be associated with the one of these > > > > that matches the > > > > > policy it has? > > > > > > > > Of course the whole notion of connection is vague in corba:-( > > > > To be honest i'm not sure what this means looking at this > > > > again - we just > > > > need a way to signify when to send the service context and on > what > > > > connections. If i say connection mode = normal and then use a > > > > bidir one this > > > > make no difference to the invocation. > > > > I need to rethink this one. > > > > > > I agree. > > > > > > I've been rethinking this one, and I have come to the > > conclusion that ORB, > > object and thread are not the correct scopes. In fact we > > don't have anything > > that is the correct scope. I think the portable interceptors > > may have a way > > round this one, but until that gets adopted we can't use it. > > I would propose > > that leave this type of policy as an implementation issue for now. > > I don't think we should close the issue on that basis. > Perhaps it will take some time to find a suitable solution. > If so, orbs are free to implement whatever they want in the > meantime. > But until this is resolved users will have to realize that they are > dependent on proprietary mechanisms. I'm happy to document this like you describe. Martin. From: Paul Kyzivat To: "'mchapman@iona.com'" , Paul Kyzivat , "Firewall RTF (E-mail)" Subject: RE: Firewall policies Date: Thu, 9 Dec 1999 17:30:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: U4>!!RGPd9;!3e9:nl!! > From: Martin Chapman [mailto:mchapman@iona.com] > > From: Paul Kyzivat [mailto:paulk@roguewave.com] > > I don't think it is all that clear when it is possible or > appropriate to > > override the policies on an object. It certainly seems like > > additional uses > > of this "feature" should be open to consideration. > > I don;t think this RTF is the appropriate place to do this. Why not, if that is what is needed to have a sensible specification? > > It is true that a server writer has the option of setting > policies on the > > POA, which a client does not. But that may not be the "right" > > granularity. I > > think this should probably be determined on a > policy-by-policy basis. > > Sure you can document what scope a policy applies to. I meant that to cover the case of applying to an individual object, even though the object is on the server side. Apparently you think this is not permissible. > lets take a step back and look at the three use models: > > 1) In some environments (browsers or other) it is not > possible to accept incomming connections. > Therefore for a callback object your only choice is use bidir. So > you > allocate a host and port number, use this in the > ior and also send it over in the bidir service context. The > client doesn't have to (or may not be able to) listen on this port > in the case of bidir only. If the client can't or won't listen on the port, then the orb must provide some way of guaranteeing that the port will not be used for any other purpose during the time that the client is using it as a target address for callbacks. In most operating systems, I don't know any way of doing this short of associating the port with a socket. If browsers, or the orb on their behalf, can't do this, then the bidir protocol is useless to them. I suppose one alternative might be to create an invalid tcp/ip address in some way that is known to be unique. But this could cause interoperability problems unless carefully specified. And guaranteeing uniqueness could be difficult (though it can be achieved with high probability). > > 2) for whatever reason (security considerations etc) you > don't want any of > your objects invoked bi-directionally. here you stick to > normal giop rules, > lisen on a port and wait for incomming connections. No problem here. > > 3) for whetever reason, you may want some of your objects to > be invoked bidir only and some normal only. We have to have a > mechanism to distinguish > the two - the only way to do this in the current spec is > through the listen > point data (a sequence of host/port pairs) so in this mixed > mode only you > have to have two distinct ports - the port for the normal > only object shoudl not be sent in th bidir service context. I still don't see any explanation of why this is useful. Why complicate implementations and consume scarce resources to do something unimportant? > > You don't need to listen to them. But you (or somebody) > needs to at least > > allocate them. Otherwise, the address may inadvertently get > picked up and > > used by another server. That could cause mass confusion for > anybody > > attempting to use your IORs without. > > true in most environments (i don't think its possible in browser > environments.) See above. If the browser can't at least guarantee that the address it chooses will not be in use by someone else, then it can't usefully implement this functionality. Reply-To: From: "Martin Chapman" To: "Paul Kyzivat" , "Firewall RTF (E-mail)" Subject: RE: Firewall policies Date: Fri, 10 Dec 1999 10:38:40 -0000 Message-ID: <001001bf42fa$b90da680$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA914022E@bos1.noblenet.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: )2od9kWjd9BJ[!!3n1e9 > -----Original Message----- > From: Paul Kyzivat [mailto:paulk@roguewave.com] > Sent: 09 December 1999 22:31 > To: 'mchapman@iona.com'; Paul Kyzivat; Firewall RTF (E-mail) > Subject: RE: Firewall policies > > > > From: Martin Chapman [mailto:mchapman@iona.com] > > > From: Paul Kyzivat [mailto:paulk@roguewave.com] > > > > I don't think it is all that clear when it is possible or > > appropriate to > > > override the policies on an object. It certainly seems like > > > additional uses > > > of this "feature" should be open to consideration. > > > > I don;t think this RTF is the appropriate place to do this. > > Why not, if that is what is needed to have a sensible specification? It changes the architecture defined in the messaging spec. That is the correct place to do this. > > > > It is true that a server writer has the option of setting > > policies on the > > > POA, which a client does not. But that may not be the "right" > > > granularity. I > > > think this should probably be determined on a > > policy-by-policy basis. > > > > Sure you can document what scope a policy applies to. > > I meant that to cover the case of applying to an individual object, > even though the object is on the server side. Apparently you > think this is not permissible. Not in the current architecture. > > > lets take a step back and look at the three use models: > > > > 1) In some environments (browsers or other) it is not > > possible to accept incomming connections. > > Therefore for a callback object your only choice is use bidir. So > you > > allocate a host and port number, use this in the > > ior and also send it over in the bidir service context. The > > client doesn't have to (or may not be able to) listen on this port > > in the case of bidir only. > > If the client can't or won't listen on the port, then the orb must > provide > some way of guaranteeing that the port will not be used for any > other > purpose during the time that the client is using it as a target > address for > callbacks. > > In most operating systems, I don't know any way of doing this short > of > associating the port with a socket. If browsers, or the orb on > their behalf, > can't do this, then the bidir protocol is useless to them. > > I suppose one alternative might be to create an invalid tcp/ip > address in > some way that is known to be unique. But this could cause > interoperability > problems unless carefully specified. And guaranteeing uniqueness > could be > difficult (though it can be achieved with high probability). This is the reasoning about setting the port to that of the local outgoing connection (issue 2638). This works, it's in our product!!! > > > > > 2) for whatever reason (security considerations etc) you > > don't want any of > > your objects invoked bi-directionally. here you stick to > > normal giop rules, > > lisen on a port and wait for incomming connections. > > No problem here. > > > > > 3) for whetever reason, you may want some of your objects to > > be invoked bidir only and some normal only. We have to have a > > mechanism to distinguish > > the two - the only way to do this in the current spec is > > through the listen > > point data (a sequence of host/port pairs) so in this mixed > > mode only you > > have to have two distinct ports - the port for the normal > > only object shoudl not be sent in th bidir service context. > > I still don't see any explanation of why this is useful. > Why complicate implementations and consume scarce resources to do > something > unimportant? Are you saying the use case is not useful, or the need for two distinct addresses? > > > > You don't need to listen to them. But you (or somebody) > > needs to at least > > > allocate them. Otherwise, the address may inadvertently get > > picked up and > > > used by another server. That could cause mass confusion for > anybody > > > attempting to use your IORs without. > > > > true in most environments (i don't think its possible in browser > > environments.) > > See above. If the browser can't at least guarantee that the address > it > chooses will not be in use by someone else, then it can't > usefully implement > this functionality. Again using the local outgoing port works. Issue 2638 though is about rewording so as not to mandate this as the only solution. Date: Fri, 10 Dec 1999 14:39:54 +0000 From: Owen Rees To: mchapman@iona.com, firewall-rtf@omg.org Subject: Re: Vote 2. - issue 2639 Message-ID: <4238956847.944836794@ews-proj-2.hpl.hp.com> In-Reply-To: <000301bf4268$dd222e20$4d01020a@leo.dublin.iona.ie> Originator-Info: login-id=ore; server=ticb.hpl.hp.com X-Mailer: Mulberry (Win32) [1.4.3, s/n P005-300802-001] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: aGH!!@4=!!Z%ad9UD`d9 --On 09 December 1999, 17:14 +0000 Martin Chapman wrote: > Issue 2639: Firewall POA Policy does not control access (firewall-rtf) The proposed revision is better, but there are some details I would prefer to change. > > Click here for this issue's archive. > Nature: Uncategorized Issue > Severity: > Summary: In orbos/98-07-03 4.9 it says "However, it is desirable to > provide a portable means by which the object implementor can decide > whether an object could be accessible through a firewall. The > following > POA policy is defined for this purpose:" but this policy can at most > control what components are included in references created by the > POA. > Since the references do not have any mechanism to defend against > forgery, > exclusion of a FirewallMechanism component does not prevent access > through a firewall. If an attacker obtains some other reference with > the > FirewallMechanism component(s), it can convert a reference created > under > NO_EXPORT into the reference that would have been created under > EXPORT. > The description of the policy needs to be changed to make it clear > that > the policy does not imply any access control enforcement. The > ability of > an attacker to forge references, either by combining parts of other > references, or otherwise, should be explicitly stated as a security > issue > that must be addressed by means outside this specification. > Resolution: > Re-phrase to make it clear that the policy is only about whether to > add > tag components or not. Revised Text: all changes relative to > orbos/98-07-03 > > Section 4.9, page 4-21, 1st para. > > replace: "In order to take advantage of the tag component defined > above, > a server side ORB must contain configuration information about the > firewalls in its domain. No interfaces for the setting or retrieving > of > firewall information in an ORB are defined as this is an > implementation > issue. However, it is desirable to provide a portable means by which > the > object implementor can decide whether an object could be accessible > through a firewall. The following POA policy is defined for this > purpose:" > > with: "In order to take advantage of the tag component defined > above, a > server side ORB must contain configuration information about the > firewalls in its domain. No interfaces for the setting or retrieving > of > firewall information in an ORB are defined as this is an > implementation > issue. However, it is desirable to provide a portable means by which > the > object implementor can indicate whether an object may be accessible "may be" is still too close to implying access control for my liking. I would prefer "is intended to be". > through a firewall. A POA policy is defined that allows an object > implementer to indicate that FirewallMechanism tag components may be "may be" implies that the POA can choose to leave out the tag componenets, but the text that follows suggests that any policy that prohibits export would have caused an InvalidPolicy exception out of create_POA. I would prefer to replace "that FirewallMechanism tag components may be" with "that any configured FirewallMechanism tag components will be". > placed in the IOR of the object. The policy does not imply any access > control enforcement, only that firewall tags are permitted in the IOR. It > is possible that an IOR created without any FirewallMechanisms could be > forged to contain them. This is potentially a serious security risk, but > it is outside the scope of this specification. The firewall POA policy is > defined as follows:" > > Section 4.9, page 4-22, after IDL at top of page: > > insert: "A policy value of NO_EXPORT means that FirewallMechanism tag > components should not be placed in any IORs for which the scope of the > policy applies (i.e. a POA). A policy value of EXPORT indicates that > FirewallMechanism tag components may be placed in IORs for which the > scope of the policy applies (i.e. a POA). Change that to: "A policy value of NO_EXPORT means that FirewallMechanism tag components will not be placed in any IORs for which the scope of the policy applies (i.e. a POA). A policy value of EXPORT indicates that the configured FirewallMechanism tag components will be placed in IORs for which the scope of the policy applies (i.e. a POA)." I.e. 'should'->'will' and 'may'->'will'. Yes, I want to take away ORB vendor freedom to implement visibly different behaviours. Do it how you like, but have the same external effect. > > > Actions taken: Close on agreement of revised text. > May 6, 1999: received issue > > Discussion: > Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 From: Paul Kyzivat To: "'mchapman@iona.com'" , Paul Kyzivat , "Firewall RTF (E-mail)" Subject: RE: Firewall policies Date: Wed, 15 Dec 1999 19:29:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: dJg!!LM1e9[~fd9=aT!! > > > 3) for whetever reason, you may want some of your objects to > > > be invoked bidir only and some normal only. We have to have a > > > mechanism to distinguish > > > the two - the only way to do this in the current spec is > > > through the listen > > > point data (a sequence of host/port pairs) so in this mixed > > > mode only you > > > have to have two distinct ports - the port for the normal > > > only object shoudl not be sent in th bidir service context. > > > > I still don't see any explanation of why this is useful. > > Why complicate implementations and consume scarce resources to do > > something unimportant? > > Are you saying the use case is not useful, or the need for > two distinct addresses? I am saying that I cannot currently conceive of a relevant application of this use case. If I am willing to receive some requests bidirectionally, what is the harm of receiving other (or all) requests bidirectionally? The client must state willingness because special machinery must be set up to handle bidir, but there don't seem to be any other particular policy concerns. It is the person doing the callbacks who needs to be selective about when/if to permit use of bidir at a fine grained level.