Hide Forgot
Affects: Documentation (Ref Guide, User Guide, etc.) Date of First Response: 2008-01-03 14:39:18 Workaround Description: Put the JBPM engine in a protection domain with limited permissions, so that dangerous stuff like System.exit , etc. will get blocked by the security manager (activated by default). project_key: SOA This may be works as design, but is also a security hole par example. By embedding script tags in processdefinition.xml used for process definition upload, any thinkable java code can be executed during the event hooks provided by jbpm. See comments for the attachment for the source code.
Attachment: Added: atimerbox.zip
Link: Added: This issue is related to SOA-262
in the web.xml, the availability of the servlet and the security authrorizations can be configured.
i don't think a security domain is the right solution. restricting access so that unauthorized people can't deploy processes is the right solution.
"Restricting access is good first step, but we still leave an open functionality and security risk" jBPM is not designed to run in a hostile environment. If you would like to make it secure you would have to start with a full audit. I'm pretty sure it will be practically impossible to find and fix all security holes. Any solution to fix the security wholes will also have an impact on all the users that don't want to run jbpm in a hostile environment. Also, we have put great care into building suite package that gives an easy out-of-the-box experience by integrating the runtime, designer and console. It's done in such a way that most of our users get going with it asap. If people have to find how to unlock things before they can start working with it, that would introduce another barrier that holds back adoption of our product. A bit of documentation to explain that the jbpm servlet is a potential security risk and how to disable it might be appropriate.
Marc is correct. Plus "If you would like to make it secure you would have to start with a full audit. I'm pretty sure it will be practically impossible to find and fix all security holes." is not a strong argument against fixing this issue particular. Change the words "secure" to "reliable" and "security holes" to "bugs" and you have a statement whereby we should never look for and fix bugs either. Of course there may be other security issues that this won't catch, but it's a start. It would appear that there are two mutually compatible ways to address this issue: sandbox jBPM via an appropriate classloader and documentation. The latter is straightforward and relatively simply to do. I need to know how long it will take you (Tom) to do the former, assuming we go down that route?
Link: Added: This issue related SOA-262
Link: Removed: This issue related SOA-262
Link: Added: This issue is related to SOA-270
i don't know what is meant with sandboxing.
that approach is not getting included in the project itself. you'll have to do it as part of the platform integration code if you want it. it's not going to be easy. count on 2 - 4 weeks of work without the jbpm learning curve. if this gets committed in the platform branch, it is too far from the project branch and I will not be able to support a solution like that.
i know what it is and i know how to do it. my response was that i don't want that kind of things in the project itself. so they can be done in the platform integration code of jbpm. but that would have big implications as i mentioned. ps. just a suggestion: i think it would be more polite to our community if you commented in public by default.
We will create two jBPM wars: one for production where the web.xml is modified to prevent such security issues and closing down the access, and one for development use, which would allow the jBPM development tool to continue to operate.
We will need to document this as well.
Link: Added: This issue is a dependency of SOA-327
Affects: Added: [Documentation (Ref Guide, User Guide, etc.)]
Link: Added: This issue related SOA-313
Fixed. Awaiting documentation update to close issue.
Information from Mike Brock: Two war files are shipped with the platform: In the standalone version, we ship with the unsecured uploader console by default. ie. the jBPM JPDL will be able to deploy processes, unless it's secured by copying the file in: /tools/resources/jbpm-console-production.war to /server/default/deploy/jbpm.esb/jbpm-console.war. They can change it back by copying: /tools/resources/jbpm-console-development.war to /server/default/deploy/jbpm.esb/jbpm-console.war. The file must be overwritten. You can not have two versions of the war in the deployment directory. In the EAP version, by default, the all profile has the development version of the WAR, and the production profile has the production version.
My favorite choice for the standalone version would be "securing it by default, and opening it (make it vulnerable) by intent". With the current setup, which is the opposite, admins are likely to forget/oversee that they have to close the jpbm hole after deploying the processes, especially if they don't use jbpm at all, which means that the upload stays open unnoticed because admins are not aware of this feature.
Link: Added: This issue is a dependency of SOA-515