-
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.
-
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>
-
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.
-
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. -
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.