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

Bugs item #969175, was opened at 2004-06-08 13:07
Message generated for change (Settings changed) made by ron_vered
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: Open
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-27 15: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 11: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 08: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 11: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-12 15: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: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php