Which path to follow to limit what an user can execute ?
Locked
 
|
Hi All,
I have the following problem... In my system you can import XPDL files generated with Bizagi (http://www.bizagi.com/en/bpm-suite/bpm-products/modeler) and it uses Orbeon forms (www.orbeon.com) to simulate each Bizagi task as an Orbeon form. For example if you have a gateway in a process which split the path in two different direction then you have to define a condition (inside Bizagi). The condition looks like: [:formProc | (formProc age > 18) and:[formProc amount < 10000]] The argument (formProc) can be an instance of OrbeonFormInstance or OrbeonFormProcess. The result of the evaluation MUST be a boolean. Until here there is NO problem, the system execute processes WITHOUT problems (even subprocesses are supported). But now i want control what the user can execute inside these Blocks that are defined inside Bizagi. For example: [:formProc | OrbeonFormProcessDefinition removeAll]. From the Process point of view there is no problem, the result is NOT a boolean --> this process will be blocked. But from Security point of view is a disaster because this will remove all process instances and definitions in the system. At first i thought that GsObjectSecurityPolicy will do the job. I define an UserProfile ("seaside") and create a policy that only has read permission. Then i use GsObjectSecurityPolicy(class)>>setCurrent:while: in order to ensure that the operation is a read operation. Not sure what happend with other sessions (other web users that are logged with the same UserProfile) But now i'm thinking to use the Parser to check that all message that are sent to the argument (formProc) and forbid the import of Bizagi models that fail this check. Now i'm checking the Parse and how to implement this... But what do you think about this problem ? Is there any other possible solution ? Regards, Bruno |
Re: [Glass] Which path to follow to limit what an user can execute ?
|
|
Hi Bruno,
Using GsObjectSecurityPolicy was a nice idea but doesn’t work quite that way. The policy is attached to objects and uses the current UserProfile to determine security. The method #’setCurrent:while:’ changes the default policy that is attached to newly instantiated objects, but does not change the current user’s access to objects that are already created. The right way to use GsObjectSecurityPolicy would be to create a single policy, one that provides read/write permission to one user/group and read-only permission to another user/group. Then you create objects when logged in as a user with read/write permission and do your read-only operations when logged in as a user with read-only permission. That is, code obtained from XPDL files should only be executed when logged in as one user, while code written by you (to handle the forms and tasks) may be executed when logged in by a more privileged user. To execute code as another user you need to login as that user. For that you have at least two options. The safest is probably GsExternalSession. See the class for its various protocols. You could also look at GsCurrentSession>>#’reloginAsUser:withPassword:’, though this method is intended for a situation where you are not trying to keep data between “logins”. As long as you are not using one of the built-in UserProfiles (such as DataCurator), you can also use the following code: System commitsDisabledUntilLogout. This way you would not need to set up a special GsObjectSecurityPolicy and use two UserProfiles. You would, however, still need to use a separate session (such as GsExternalSession described above). This way you can make any session effectively read-only. That is, it can still edit objects (including removing all forms), but it can’t commit so it doesn’t matter. Here is one alternative to consider: When a method is compiled you provide a SymbolList that identifies the globals visible to the code being compiled. If this list did not include OrbeonFormProcessDefinition then it would be more difficult (though not impossible!) to reach the global. If you are trying to prevent accidental errors, then this may be sufficient. If you want to protect against malicious code, then executing it in a separate read-only session is best. I’m not sure what you would learn from parsing the input. If you want to find out what messages are sent, you could look at the compiled method’s #’literals’ array. If you had a very limited number of approved selectors, then you could verify things that way. Does that help? James > On May 20, 2015, at 7:52 AM, BrunoBB via Glass <[hidden email]> wrote: > > Hi All, > > I have the following problem... > > In my system you can import XPDL files generated with Bizagi > (http://www.bizagi.com/en/bpm-suite/bpm-products/modeler) and it uses Orbeon > forms (www.orbeon.com) to simulate each Bizagi task as an Orbeon form. > > For example if you have a gateway in a process which split the path in two > different direction then you have to define a condition (inside Bizagi). > The condition looks like: > [:formProc | (formProc age > 18) and:[formProc amount < 10000]] > > The argument (formProc) can be an instance of OrbeonFormInstance or > OrbeonFormProcess. > The result of the evaluation MUST be a boolean. > > Until here there is NO problem, the system execute processes WITHOUT > problems (even subprocesses are supported). > > But now i want control what the user can execute inside these Blocks that > are defined inside Bizagi. > > For example: > [:formProc | OrbeonFormProcessDefinition removeAll]. > > From the Process point of view there is no problem, the result is NOT a > boolean --> this process will be blocked. > > But from Security point of view is a disaster because this will remove all > process instances and definitions in the system. > > At first i thought that GsObjectSecurityPolicy will do the job. I define an > UserProfile ("seaside") and create a policy that only has read permission. > Then i use GsObjectSecurityPolicy(class)>>setCurrent:while: in order to > ensure that the operation is a read operation. Not sure what happend with > other sessions (other web users that are logged with the same UserProfile) > > But now i'm thinking to use the Parser to check that all message that are > sent to the argument (formProc) and forbid the import of Bizagi models that > fail this check. > > Now i'm checking the Parse and how to implement this... > > But what do you think about this problem ? Is there any other possible > solution ? > > Regards, > Bruno > > > > -- > View this message in context: http://forum.world.st/Which-path-to-follow-to-limit-what-an-user-can-execute-tp4827662.html > Sent from the GLASS mailing list archive at Nabble.com. > _______________________________________________ > Glass mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Which path to follow to limit what an user can execute ?
|
|
In reply to this post by BrunoBB
Hi Bruno, Just wanted to say I am experiencing the same issue. In my app we have a rule engine where the advanced user can script, create its own rules etc. This rules are basically a closure. And that means...they can execute everything: 1) break the system very easily, 2) steal all my source code, 3) other. For stealing source code, I send another email to the mailing list the other day but didn't get much answers besides "don't worry". I also thought about parsing the code and be sure I only send messages to the "processor" which is the one argument we pass around to such rules/closures. I wonder if others have ever done a rule engine with certain security provided. On Wed, May 20, 2015 at 11:52 AM, BrunoBB via Glass <[hidden email]> wrote: Hi All, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Which path to follow to limit what an user can execute ?
|
|
In reply to this post by GLASS mailing list
Bruno,
Another approach is suggested by GLORP’s use of blocks for a WHERE clause. It looks like a regular block but instead of passing in each row (as implied by the usage), the block is evaluated only once and a message accumulator is passed in that implements #’doesNotUnderstand:’ to capture each message and arguments. This message accumulator is then used to generate the actual query. In conjunction with a limited SymbolList (to avoid visibility of any unauthorized globals), this could come close to what you need (but again would not be completely secure). James > On May 20, 2015, at 9:08 AM, James Foster <[hidden email]> wrote: > > Hi Bruno, > > Using GsObjectSecurityPolicy was a nice idea but doesn’t work quite that way. The policy is attached to objects and uses the current UserProfile to determine security. The method #’setCurrent:while:’ changes the default policy that is attached to newly instantiated objects, but does not change the current user’s access to objects that are already created. > > The right way to use GsObjectSecurityPolicy would be to create a single policy, one that provides read/write permission to one user/group and read-only permission to another user/group. Then you create objects when logged in as a user with read/write permission and do your read-only operations when logged in as a user with read-only permission. That is, code obtained from XPDL files should only be executed when logged in as one user, while code written by you (to handle the forms and tasks) may be executed when logged in by a more privileged user. > > To execute code as another user you need to login as that user. For that you have at least two options. The safest is probably GsExternalSession. See the class for its various protocols. You could also look at GsCurrentSession>>#’reloginAsUser:withPassword:’, though this method is intended for a situation where you are not trying to keep data between “logins”. > > As long as you are not using one of the built-in UserProfiles (such as DataCurator), you can also use the following code: > System commitsDisabledUntilLogout. > This way you would not need to set up a special GsObjectSecurityPolicy and use two UserProfiles. You would, however, still need to use a separate session (such as GsExternalSession described above). This way you can make any session effectively read-only. That is, it can still edit objects (including removing all forms), but it can’t commit so it doesn’t matter. > > Here is one alternative to consider: When a method is compiled you provide a SymbolList that identifies the globals visible to the code being compiled. If this list did not include OrbeonFormProcessDefinition then it would be more difficult (though not impossible!) to reach the global. If you are trying to prevent accidental errors, then this may be sufficient. If you want to protect against malicious code, then executing it in a separate read-only session is best. > > I’m not sure what you would learn from parsing the input. If you want to find out what messages are sent, you could look at the compiled method’s #’literals’ array. If you had a very limited number of approved selectors, then you could verify things that way. > > Does that help? > > James > > >> On May 20, 2015, at 7:52 AM, BrunoBB via Glass <[hidden email]> wrote: >> >> Hi All, >> >> I have the following problem... >> >> In my system you can import XPDL files generated with Bizagi >> (http://www.bizagi.com/en/bpm-suite/bpm-products/modeler) and it uses Orbeon >> forms (www.orbeon.com) to simulate each Bizagi task as an Orbeon form. >> >> For example if you have a gateway in a process which split the path in two >> different direction then you have to define a condition (inside Bizagi). >> The condition looks like: >> [:formProc | (formProc age > 18) and:[formProc amount < 10000]] >> >> The argument (formProc) can be an instance of OrbeonFormInstance or >> OrbeonFormProcess. >> The result of the evaluation MUST be a boolean. >> >> Until here there is NO problem, the system execute processes WITHOUT >> problems (even subprocesses are supported). >> >> But now i want control what the user can execute inside these Blocks that >> are defined inside Bizagi. >> >> For example: >> [:formProc | OrbeonFormProcessDefinition removeAll]. >> >> From the Process point of view there is no problem, the result is NOT a >> boolean --> this process will be blocked. >> >> But from Security point of view is a disaster because this will remove all >> process instances and definitions in the system. >> >> At first i thought that GsObjectSecurityPolicy will do the job. I define an >> UserProfile ("seaside") and create a policy that only has read permission. >> Then i use GsObjectSecurityPolicy(class)>>setCurrent:while: in order to >> ensure that the operation is a read operation. Not sure what happend with >> other sessions (other web users that are logged with the same UserProfile) >> >> But now i'm thinking to use the Parser to check that all message that are >> sent to the argument (formProc) and forbid the import of Bizagi models that >> fail this check. >> >> Now i'm checking the Parse and how to implement this... >> >> But what do you think about this problem ? Is there any other possible >> solution ? >> >> Regards, >> Bruno >> >> >> >> -- >> View this message in context: http://forum.world.st/Which-path-to-follow-to-limit-what-an-user-can-execute-tp4827662.html >> Sent from the GLASS mailing list archive at Nabble.com. >> _______________________________________________ >> Glass mailing list >> [hidden email] >> http://lists.gemtalksystems.com/mailman/listinfo/glass > _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Which path to follow to limit what an user can execute ?
|
|
In reply to this post by GLASS mailing list
Mariano,
Sorry I missed your message ... I've been incommunicado as I've been focusing solely on 3.3 work (with a code freeze coming up real soon now) and really don't have the cycles right now respond to email ... Bruno and Mariano, With PetitParser now ported to GemStone 3.2 and the important bits of RB in GsDevKit/GLASS (at least the important parts ... I think), you could consider doing a validation of the proposed script against a known set of classes and methods (basically enforcing an Interface for the "legal" Smalltalk API)... combining that with a restricted SymbolList and perhaps jiggering the ObjectSecurityPolicy so that folks cannot install new methods or classes just might give you pretty good confidence that the users aren't doing questionable things ... re-entering the cave:) Dale On 05/20/2015 09:08 AM, Mariano
Martinez Peck via Glass wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
In reply to this post by GLASS mailing list
James,
/********************************************************************************/ The policy is attached to objects and uses the current UserProfile to determine security. The method #’setCurrent:while:’ changes the default policy that is attached to newly instantiated objects, but does not change the current user’s access to objects that are already created. /********************************************************************************/ Now that you metion that i remember that i read this in the GS manual. The GS64 the policy has session boundary and GS32 has transaction boundary with Security Policies (or something like this). I have to read more in the GS manuals in order to find the right way but you give me with very good information. I will investigate GsExternalSession and the other option you mention. Thanks very much for the info i will perform some simple test will all possibilities in order to know how to proceed. The parser idea is to detect what messages are sent and the receivers of these messages. I will check #literals of a Block. In my case all messages must sent to the block argument. [:form | form amount > 1000]. I think the rule is that all message must be sent to the argument of the block or to a "simple object" (integer, string, and so on). To be honest i have to investigate further on this issue .... After the investigation i will post the solution i chose. Thanks again for the information... Regards, Bruno |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |