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

Eamonn,

Thank you for all your comments!

Ron.

Reply-To: mx4j-devel

Ron Vered wrote:
 > Éamonn McManus wrote:
>> If this Subject's permissions were not
>> intersected with the creator of the connector server (1), then 1 
>> could create an RMIConnectorServer with a JMXAuthenticator that 
>> always returns a 3 that is a highly-privileged Subject.  1 could then 
>> connect to itself and execute code with the permissions of 3

> So what is the alternative? Make (1) have AllPermissions (or something 
> close to it)? So you get same result. In fact, I think its not same 
> result, it is has the great disadvantage that this (1) is pretty much 
> constantly running at high privilege. With RMI and object 
> serialization, it can potentially load some malicious code from a 
> client and run it in high privilege. If run in low privilege, then 
> even if you forgot some hole, malicious code will have hard time doing 
> anything useful.

Yes, (1) does need to have a strong set of permissions.  I do not see a 
security problem with serialization, or with code downloading which is 
probably what you are thinking of.  Even if an evil client does manage 
to download code into the server, that code will have no permissions 
because, unlike the code that created the RMI connector server, its 
codebase will not be mentioned in the java.policy file.
[Ron] maybe not, it may be principal based permission (which is what I am discussing)
The fact of the matter is you are unnecessarily running in high privilege which opens the door
To all sort of exploits which will not be possible at low privilege.

There is little point in making it possible for the connector server to 
have low privilege if it is done in such a way as to allow it to amplify 
that privilege at will.
[Ron] the Subject can be explicitly trusted to do this, which will achieve overall better security
Because things have exactly the permissions they need, instead of artaficially adding permissions.
Like the guard to the oval office (see below).
Please change the phrase 'at will' to 'as trusted to do'.

Then malicious code *will* be able to do useful 
things.
[Ron] (didn't you just said will not because of different code base?) It will have to go through a two step process to do this: compromise the server in a specific way so as to capture control at a later time, then sit and wait for high privileged user to come along.
In current design, you need only to compromise the server, since it already has permission.

> Then there is the problem of initialization. If the server is a daemon 
> (and needs high privileges) the problem of where to store its 
> credentials becomes more difficult because the extra care required.

In other words, you need to set up your java.policy carefully, yes.
[Ron] not enough, you need to store a sensitive secret somewhere. With unnecessary high privilege, getting this secret can be a one step process for a malicious client.

> I think that although (1) may have low privileges, it still can be 
> trusted in someway. To use the president allegory, the guards to the 
> oval office don't have the privilege to launch ICBMs, but the do 
> control if the president is allowed in or not to push the button.

Interesting allegory.  A corrupt guard can let in someone who is not the 
president, and that someone can then push the button.  So if you don't 
trust the guard not to push the button then you can't trust him to 
decide who does.  This translates exactly to the case at hand.
[Ron] That's right! Guard does NOT have permission to push the button!
He only facilitates the transport of the president to do it. He is trusted in a limited way.
It would not make sense to give the guard the permission to push the button only so the president could do it. In fact, the world would be much less secure if the guard had permission to do it, and thankfully, there is no artificial need to give the guard this privilege!

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

> [Ron] I want to clarify this point (so we did not make an incorrect
> conclusion): If the "authenticated subject from a connection", which I 
> refer to as (2), does not have say FilePermission AND the delegate 
> Subject (3) does have it, and then the code goes ahead and does a file 
> operation through some MBean, before this fix, will it fail or 
> succeed? I think it will fail because (2) does not have this 
> permission, but correct me if I am wrong. This is, in fact the aspect 
> MORE CRITICAL to us in fact, we don't care that much if (1) will have 
> high privileges.

I cannot speak for MX4J, but with the Reference Implementation, (2) does 
not need to have FilePermission.  (1) and (3) do.
[Ron] Let me check this again.

Regards,
-- 
Éamonn McManus, JSR 160 (JMX Remote API) Spec Lead

[Ron] PLEASE add a way for delegate to specify credentials, instead of passing Subject:
JMXConnector.getMBeanServerConnection(Subject delegationSubject)  // <== what exists today
JMXConnector.getMBeanServerConnection(credentials)                // <== what we request

------------------------------------------------------------------------------
This e-mail message is for the sole use of the intended recipient(s) and contains confidential and/or privileged information belonging to Siebel Systems, Inc. or its customers or partners.  Any unauthorized review, use, copying, disclosure or distribution of this message is strictly prohibited.  If you are not an intended recipient of this message, please contact the sender by reply e-mail and destroy all soft and hard copies of the message and any attachments.  Thank you for your cooperation.
====================================================



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