5 Replies Latest reply on Nov 7, 2005 11:23 AM by starksm64

Security hole needs plugging for 1.0.2 release

adrian.brock Oct 19, 2005 11:52 AM

So I've fixed the MC to work correctly under a security manager.

However, the current fix introduces a security hole in the callouts to bean operations:
http://jira.jboss.com/jira/browse/JBMICROCONT-51

The issue is that the bean operations like construction, setters, start/stop, etc.
are now invoked using the controller's access control context,
meaning that anybody can now deploy an xml file to potentially do *BAD* things!

I think the more correct semantic is to save the access control context
of the code that created the ControllerContext (bean deployment) and switch to
that to invoke bean callouts.
That way, nobody can use a bean deployment to gain extra permissions.

1. Re: Security hole needs plugging for 1.0.2 release

starksm64 Oct 19, 2005 4:16 PM (in response to adrian.brock)

I would say so but will take a look.
Actions
2. Re: Security hole needs plugging for 1.0.2 release

adrian.brock Oct 19, 2005 4:31 PM (in response to adrian.brock)
An example might be:

<bean name="BadBean" class="java.lang.Object"> <constructor factoryMethod="halt" factoryClass="java.lang.System"/> </bean>
Actions
3. Re: Security hole needs plugging for 1.0.2 release

starksm64 Nov 6, 2005 7:34 PM (in response to adrian.brock)

A somewhat related issue is the current testsuite usage of a global security policy for the testsuite codebase. I had to hack this to add runtime permissions for the class loader creation needed by the mock vfs class loaders. It would be good if a fine grained security context could be specified for certain testsuite classes without having to package them in a seperate directory/jar in order to be able to assign a codebase for permissions. I wonder if a package based permission scheme would be possible.
Actions
4. Re: Security hole needs plugging for 1.0.2 release

adrian.brock Nov 7, 2005 11:07 AM (in response to adrian.brock)

"scott.stark@jboss.org" wrote:
I wonder if a package based permission scheme would be possible.

We'd need to play around with junit's classloading such that the packages have
different protection domains/code bases.

P.S. I already fixed the problem on this thread.
Actions
5. Re: Security hole needs plugging for 1.0.2 release

starksm64 Nov 7, 2005 11:23 AM (in response to adrian.brock)

Yes, I saw the change to handle the context, but I mentioned this issue here as it could be possible to decorate the context with an identity to perform security checks based on who rather than from where the code comes. I'm not a fan of URL based permissions in an app server as it generally imposes an unnecessary seperation of code.
Actions

Go to original post