Re: RE: [Mx4j-user] RE: mx4j-Bugs-969175: Security and delegation

Bordet, Simone wrote:
> Hi Eamonn, 
>>I am not saying this can't be changed in a future version of 
>>the API.  I am simply saying that the proposed change in the 
>>semantics of the existing implementations is insecure and 
>>cannot be made.
>>
>>You are right that the situation where the creator of a 
>>connector server must have all the permissions that any 
>>client of the server will need is suboptimal.  It should be 
>>possible to give the creator just the permissions it needs to 
>>create the connector server.
> 
> I still haven't understood if you think the alternative implementation
 > has a security hole or not. I think it has not.

I think it has.

> Eamonn, I have understood your example where a connector can return
 > non-authenticated users. But I think it does not demonstrate any
 > security hole, and I am still not convinced.

I don't get you.  Usually, jmx-remote.jar (or whatever the MX4J 
equivalent is) would be installed with AllPermission, right?  Certainly 
when it lives in J2SE this is the case.  So, if I have a setup where 
this is the case, and where some other code "creator" has 
SocketPermission but no other permission, and where there is a Subject 
"eraser" that has some other permissions, and where there is an MBean 
that needs those permissions, then "creator" can invoke that MBean 
without having the requisite permissions.  Therefore the security model 
is violated.  It doesn't matter that this might not be a very usual 
configuration.  It doesn't matter that you *can* set things up securely. 
  The point is that you are providing a library that could in some 
circumstances allow people to subvert the security model.  That is bad.

The fact that this is not the default behaviour does change things.  If 
the new behaviour is only turned on if you set a system property, and if 
you document the security risk of setting the property, then there 
should not be a problem.  If the new behaviour is turned on by supplying 
a property in the environment Map when you create the connector server, 
then there *is* a problem, since evil code can supply that property.  I 
think that the SubjectDelegationPermission solution is much cleaner than 
setting a system property.

Just to be clear, the change whereby the authenticated Subject does not 
need specific permissions (other than SubjectDelegationPermission) if it 
delegates to another Subject is all right, and is what the RI already 
does.  You do not need a special switch to turn that on.  What's 
dangerous is ignoring the permissions of the connector server's creator.

Concerning the rest of your message, I agree with the contents of the 
policy files you show.  The fact that the "Alternate implementation" 
allows simpler configuration is irrelevant since it also subverts 
security.  The "Proposed implementation" is not materially more 
difficult, since if you do want the behaviour of the "Alternate 
implementation" you only have to add one line to the grant for 
"jmxconnectorserver.jar":

     permission SubjectDelegationPermission "*";

-- 
Éamonn

> Also, I'm seeing the issue more from the point of view of the person that has to make the system work.
> The assumption is that the system must allow a certain principal to delete files.
> The assumption is that no codebase is trusted: it must have the least set of permissions possible.
> 
> The only policy file that allow a non-trusted "jmxconnectorserver.jar" to delete files is the first, the default implementation.
> The proposed solution buys nothing for one more permission.
> 
> But sure we must discuss this better.
> 
> In almost-policy-file-syntax:
> 
> Current implementation:
> ~~~~~~~~~~~~~~~~~~~~~~~
> 
> grant codebase "jmxconnectorserver.jar"
> {
>    permission SocketPermission "localhost","listen";
>    permission SocketPermission "*:1024-","accept";
> 
>    permission FilePermission "<<ALL FILES>>","delete";
> };
> 
> grant principal "eraser"
> {
>    permission MBeanPermission "com.acme.Eraser","invoke";
>    permission FilePermission "<<ALL FILES>>","delete";
> };
> 
> 
> Alternate implementation:
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> grant codebase "jmxconnectorserver.jar"
> {
>    permission SocketPermission "localhost","listen";
>    permission SocketPermission "*:1024-","accept";
> };
> 
> grant principal "eraser"
> {
>    permission MBeanPermission "com.acme.Eraser","invoke";
>    permission FilePermission "<<ALL FILES>>","delete";
> };
> 
> Proposed implementation:
> ~~~~~~~~~~~~~~~~~~~~~~~~
> 
> grant codebase "jmxconnectorserver.jar"
> {
>    permission SocketPermission "localhost","listen";
>    permission SocketPermission "*:1024-","accept";
> 
>    permission SubjectDelegationPermission "eraser";
> };
> 
> grant principal "eraser"
> {
>    permission MBeanPermission "com.acme.Eraser","invoke";
>    permission FilePermission "<<ALL FILES>>","delete";
> };


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id808&op=click