Bug 44918 - Allow to pass a custom config.xml resource path via Init.init() method
Summary: Allow to pass a custom config.xml resource path via Init.init() method
Status: NEW
Alias: None
Product: Security - Now in JIRA
Classification: Unclassified
Component: Signature (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: XML Security Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-01 09:28 UTC by Marc Giger
Modified: 2009-06-23 07:48 UTC (History)
0 users



Attachments
allow to pass custom config (1.32 KB, patch)
2008-05-01 09:32 UTC, Marc Giger
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Giger 2008-05-01 09:28:44 UTC
If xmlsec is used in an container env, every webapp can now use its own config and
and dont rely on the global one.

Attached is a patch which is tested against xmlsec trunk.

Feel free to include/modify/extend/decline the attached patch
Comment 1 Marc Giger 2008-05-01 09:32:35 UTC
Created attachment 21898 [details]
allow to pass custom config
Comment 2 coheigea 2009-06-22 04:44:27 UTC
This patch seems fine to me. Sean, can you confirm?

Colm.
Comment 3 sean.mullan 2009-06-22 11:58:35 UTC
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?
Comment 4 Marc Giger 2009-06-22 23:40:01 UTC
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
Comment 5 sean.mullan 2009-06-23 06:57:41 UTC
(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.
Comment 6 Marc Giger 2009-06-23 07:33:38 UTC
(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.
Comment 7 sean.mullan 2009-06-23 07:48:52 UTC
(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.