| Summary: | Allow to pass a custom config.xml resource path via Init.init() method | ||
|---|---|---|---|
| Product: | Security - Now in JIRA | Reporter: | Marc Giger <gigerstyle> |
| Component: | Signature | Assignee: | XML Security Developers Mailing List <security-dev> |
| Status: | NEW --- | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: | allow to pass custom config | ||
|
Description
Marc Giger
2008-05-01 09:28:44 UTC
Created attachment 21898 [details]
allow to pass custom config
This patch seems fine to me. Sean, can you confirm? Colm. This patch contains a potential security hole which can allow untrusted code (ex: an unsigned applet) to replace the xml security configuration which could be part of a trusted installation. You can already specify a custom configuration by setting a system property and this is more secure since your code needs to have permission to set that property. To the submitter: have you tried specifying your custom config with the org.apache.xml.security.resource.config property? Sean, Yes, we always pass the custom config via org.apache.xml.security.resource.config property. The problem with this solution is the inability to specify different configs for e.g. different webservices in the same Container/VM. On the other hand I see your point with the security concern. Perhaps we can add a custom Permission class to check against current active SecurityManager/SecurityPolicy if we are allowed to set the config? Altough I've never done this. What do you think? Marc (In reply to comment #4) > Sean, > > Yes, we always pass the custom config via > org.apache.xml.security.resource.config > property. The problem with this solution is the inability to specify different > configs for e.g. different webservices in the same Container/VM. Ok, but I believe that requires changes to support multiple configurations in the same VM. Right now, there is only one configuration per VM. So this patch doesn't solve that problem. > On the other hand I see your point with the security concern. > Perhaps we can add a custom Permission class to check against current active > SecurityManager/SecurityPolicy if we are allowed to set the config? Altough > I've never done this. > > What do you think? I think if you added a per-App/container configuration such that it wouldn't affect any other threads in the same VM then you may not need to protect it with a permission. (In reply to comment #5) > (In reply to comment #4) > > Sean, > > > > Yes, we always pass the custom config via > > org.apache.xml.security.resource.config > > property. The problem with this solution is the inability to specify different > > configs for e.g. different webservices in the same Container/VM. > > Ok, but I believe that requires changes to support multiple configurations in > the same VM. Right now, there is only one configuration per VM. > So this patch doesn't solve that problem. I think it does;-) but perhaps I didn't express myself correctly: What I meant is when I have multiple web-apps deployed (e.g webservices) and every deployment has it's own copy of xmlsec.jar then the org.apache.xml.security.Init class will be loaded multiple times, once per webapp beause of the class loader hirarchy. No? > > > On the other hand I see your point with the security concern. > > Perhaps we can add a custom Permission class to check against current active > > SecurityManager/SecurityPolicy if we are allowed to set the config? Altough > > I've never done this. > > > > What do you think? > > I think if you added a per-App/container configuration such that it wouldn't > affect any other threads in the same VM then you may not need to protect it > with a permission. (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Sean, > > > > > > Yes, we always pass the custom config via > > > org.apache.xml.security.resource.config > > > property. The problem with this solution is the inability to specify different > > > configs for e.g. different webservices in the same Container/VM. > > > > Ok, but I believe that requires changes to support multiple configurations in > > the same VM. Right now, there is only one configuration per VM. > > So this patch doesn't solve that problem. > > I think it does;-) but perhaps I didn't express myself correctly: > What I meant is when I have multiple web-apps deployed (e.g webservices) and > every deployment has it's own copy of xmlsec.jar then the > org.apache.xml.security.Init class will be loaded multiple times, once per > webapp beause of the class loader hirarchy. No? Ok, I see now. Yes, I believe you're right. Let me think about this some more and get back to you. |