[ mx4j-Bugs-969175 ] Permissions at start() vs permissions during invocation

Bugs item #969175, was opened at 2004-06-08 22:07
Message generated for change (Comment added) made by biorn_steedom
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=969175&group_id=47745

>Category: JSR 160 Implementation
Group: Release 2.0.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ron V (ron_vered)
>Assigned to: Simone Bordet (biorn_steedom)
>Summary: Permissions at start() vs permissions during invocation

Initial Comment:
Current implementation constricts the set of permissions 
a delegate have to the permission intersection (minimum 
of) { JMX jars, context at start(), permissions of 
connection establisher Subject, delegate Subject }.
Even if this security model does not work for us, there is 
no way to escape it. In fact, it is hard coded.

The following security model is not possible:
Low-privileged daemon server is running with just 
enough permissions to do what it needs to on a regular 
basis, whereas, a well-privileged (authenticated) user 
can make the server take sensitive actions (which the 
daemon cannot do otherwise).

Moreover, if a low-privileged deamon created a 
connection, there is no way a more privileged user can 
make use of this connection to do its actions; the 
current implementation hard-codes the above minimal 
intersection.

The model in which the creator of a connection has to 
have permission to anything that a delegate may want 
to do is similar to the person having keys to the white-
house also having permission to launch ICBMs.

For the same reason, the entity which start()-ed the 
connector server need not have permssion to do a 
specific operation on a specific MBean.


----------------------------------------------------------------------

>Comment By: Simone Bordet (biorn_steedom)
Date: 2004-08-28 00:44

Message:
Logged In: YES 
user_id=128193

I have committed in CVS a fix for this bug.
However, the default behavior is still consistent with the
reference implementation, for compatibility, though I agree
that the current one may not be the optimal one.
To enable the alternative behavior, pass the property
MX4JRemoteConstants.SECURITY_COMBINE_START_CONTEXT with
value "false" to the environment when creating the
JMXConnectorServer.
I am closing this bug, but feel free to comment/reopen it.

----------------------------------------------------------------------

Comment By: Ron V (ron_vered)
Date: 2004-06-18 20:55

Message:
Logged In: YES 
user_id=706543

Please concentrate your effort on the second issue:
(suppose start() was done with high priviledge):
2. (Much more important to us): "Client" making a connection 
with low privileged user (the daemon), cannot delegate this 
connection to a high privileged user, without forever reducing 
connection's privileges

----------------------------------------------------------------------

Comment By: Simone Bordet (biorn_steedom)
Date: 2004-06-18 17:57

Message:
Logged In: YES 
user_id=128193

I've been able to reproduce the case, by simplifying (a
*lot* ;) your files.
I suspect there can be a security hole by not restricting
security checks using the access control context at start
time, but it will take some time to check.


----------------------------------------------------------------------

Comment By: Ron V (ron_vered)
Date: 2004-06-14 20:43

Message:
Logged In: YES 
user_id=706543

In example you see:
1. "Server" has to initialize JMX (call start()) with 
AllPermissions, for no good reason.

2. (Much more important to us): "Client" making a connection 
with low privileged user (the daemon), cannot delegate this 
connection to a high privileged user, without forever reducing 
connection's privileges.


----------------------------------------------------------------------

Comment By: Simone Bordet (biorn_steedom)
Date: 2004-06-13 00:22

Message:
Logged In: YES 
user_id=128193

I have probably understood what you're saying, but to be
100% sure it would be better if you post code and policy files.

What are you trying to achieve that the current
implementation does not allow you to do ?

Running the server with a minimal set of permissions may not
be as simple as one can think, given the Java security model.

As I've said, I probably have an idea of your problem and (I
think) a very simple solution for it, but I definitely need
more details.

Regards

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=969175&group_id=47745


-------------------------------------------------------
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_id=5047&alloc_id=10808&op=click