[ 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 (Comment added) 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: 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: Ron V (ron_vered)
Date: 2004-10-12 15:46

Message:
Logged In: YES 
user_id=706543

I have tested with nightly build I got today (Oct-12-04) and 
it seems to be fixed. The described problem DOES happen in 
2.0.1.

SocketPermission("accept"): in release 2.0.1 the Subject 
established at the server by JMXAuthenticator using client's 
credentials ("Connector") is REQUIRED to have 
SocketPermission("accept") for the server to accept the 
connection. Which is a mistake.

However, in the above nightly build the requirement is 
dropped. So this bug was fixed by someone.

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

Comment By: Simone Bordet (biorn_steedom)
Date: 2004-10-09 08:06

Message:
Logged In: YES 
user_id=128193

I have implemented was discussed via email and proposed by
Eamonn, therefore I think this bug can be closed.

Ron, I'm not sure I have understood your last comment.

Point 3 is not true (anymore, at least with the tests I've
done) in the latest CVS. 

Point 4 is normal, if permissions are granted in the usual
way: AllPermission to JMX jars and detailed permissions to
other jars.

Your last point (SocketPermission "accept") is not a
mistake: it's how SocketPermissions work. It is not enough
to be able to listen to a port. You must also grant
permission to accept incoming calls.

As usual, feel free to comment/reopen it.

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

Comment By: Ron V (ron_vered)
Date: 2004-09-21 13:26

Message:
Logged In: YES 
user_id=706543

I think only one aspect described was addressed. The other 
aspect was not.

Consider following scenario (the following was tried using RMI):
1. When JMX Server is started, it is started with a Subject 
with AllPermissions (so the point addressed by biorn does not 
apply).
The server has an MBean with an attribute ("Attribute") which 
requires MBeanPermission 'setAttribute' ("Permission").

2. A client connects to the server, its credentials establish a  
Subject on the server side ("Connector"). Connector has the 
Permission.

3. a security delegate is specified by the client ("Delegate"). 
It does not have Permission. However, Delegate is succeeds 
in doing setAttribute on Attribute.

4. If, in addition to the MServer check, a redundant check is 
placed explicitly inside the set method for Attribute, the 
MServer check succeeds whereas a security exception is 
thrown inside the set method.

In fact, in the reverse situation, where Connector does not 
have Permission and Delegate does have it, setAttribue should 
succeed:

====================
> Note that the authenticated subject from a connection does
> not need to 
> have any permissions other than SubjectDelegatePermission 
and 
> possibly 
> some JMX permissions.  It doesn't need to have 
FilePermission or 
> whatever, provided that remotely-invoked operations that 
need those 
> permissions do them through a delegated Subject.  However 
1 
> does need to have these permissions.  

True.
The corollary is that "server.jar" needs to be granted all 
permissions needed by the application. I'm not sure this is 
good.

Thanks for sharing your thoughts.
I think this is a point that should be cleared for JMX 2.0, also 
taking in account non-rmi transports that can lower the 
security level.

Regards,
Simon
===================


Last, for some odd reason, the SERVER needs for Connector 
to have SocketPermission 'accept', or otherwise connection 
will fail. This seems to be a mistake.

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

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: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl