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

Ron,

Well, don't give up that easily! :-)

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.  The main reason 
for this is to avoid having code *accidentally* do operations it 
shouldn't, rather than to protect against malicious code.  (Likewise, 
when I work on my Solaris workstation I am logged in as myself rather 
than as the superuser, even though I do know the superuser password. 
This limits the amount of damage I can do if I make a mistake.)

Here's how we could consider changing the API.  Suppose a security 
context (subject and/or codebase and/or signers), say "creator", makes a 
JMXConnectorServer and supplies a JMXAuthenticator.  Later, a connection 
arrives, and the JMXAuthenticator returns a Subject for it containing 
the Principal "remote".  Today, basically both "remote" and "creator" 
must have all needed permissions for the reason I detailed.  However, 
suppose we say that an MBean operation that needs FilePermission is 
allowed if EITHER:
(1) both "remote" and "creator" have FilePermission (the current 
requirement); OR
(2) "remote" has FilePermission and "creator" has 
SubjectDelegationPermission("remote").

In other words, by granting SubjectDelegationPermission("remote") to 
"creator", I am saying that I trust it to grant "remote"'s permissions 
to anyone (which includes to itself).  This is a logical extension of 
the existing meaning of SubjectDelegationPermisison.  Now I can 
configure "creator" so that it can create a connector server, and I can 
explicitly decide what Subjects it can legitimately return from its 
JMXAuthenticator.  I can grant it SubjectDelegationPermission("*") to 
say that I trust it to return any Subject.

The spec today does not explicitly describe how permission checking 
works, so arguably we could already change the Reference Implementation 
to follow the above model.  However, I would be reluctant to do so, 
because it is an important semantic change, and does not correspond to 
anything described by the spec.  This is definitely something we could 
consider for the next version of the API, though, and I think the MX4J 
implementation, which doesn't haven't the constraint of being the 
Reference with a capital R, could do this as of now.  It should not be 
too hard to implement, using AccessController.doPrivileged.

---

Concerning your second request, to be able to have several authenticated 
Subjects use the same RMI connection without using delegation, I am not 
convinced that this gets you enough, compared with simply opening a 
connection per authenticated Subject, to justify the additional 
complexity.  RMI can share the actual network connections between a pair 
of JVMs anyway -- it doesn't have to open a different TCP/IP connection 
for each RMI connection, except in circumstances (involving socket 
factories) where it would be impossible to share the JMX Remote 
connection anyway.

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

Ron Vered wrote:
> Eamonn,
> 
> I respectfully disagree with you.
> Even though I would like to argue for my ideas, it seems to be an uphill battle with too much resistance to change and too little to gain from it (we simply have a workaround this hurdle).
> 
> Please keep open mind for future comments you may get, making options available for developers to use other methods without too much restrictions, so the industry will not have to spend too much time on working around these restrictions.
> 
> Thank you,
> Ron.
> 
> -----Original Message-----
> From: Eamonn McManus [mailto:[email protected]] 
> Sent: Thursday, September 02, 2004 10:18 AM
> To: Ron Vered
> Cc: MX4J-Dev (E-mail); Bordet, Simone
> Subject: Re: [Mx4j-user] RE: mx4j-Bugs-969175: Security and delegation
> 
> 
> (I've removed mx4j-user from the cc list.)
> 
> Ron,
> 
> Ron Vered wrote:
> 
>>I think that kind of scenario falls into the category of malicious 
>>code,
>>which should not be trusted at all.
> 
> 
> You can't tell a priori whether code is malicious or not.  You can only 
> decide how far you trust it.  You must give lots of permissions to code 
> that starts a connector server if you want operations through that 
> connector server to work.  This tells you that you need to trust that 
> code.  That in turn tells you that you must only give it those 
> permissions if indeed you do trust it a lot.  This is the right way for 
> this to work.
> 
> Let's run through this again.  Someone ("creator") creates a connector 
> server and hooks it up to an MBeanServer that contains a 
> FileDeleteMBean.  "creator" doesn't have FilePermission so can't delete 
> files.  But there exists a principal "eraser" that does have 
> FilePermission.  If a request comes through the connector server to call 
> the FileDeleteMBean, what permissions should be consulted?
> 
> Suppose only the permissions of the authenticated subject are consulted. 
>   Then all "creator" has to do is arrange for the authenticated subject 
> to be "eraser".  An incoming request can now delete files.  In other 
> words, "creator" has been able to arrange for files to be deleted, even 
> though it doesn't have FilePermission.  This is what I mean by 
> permission amplification.
> 
> The key point here is that when "creator" creates an RMIConnectorServer, 
> it gets to decide how authentication works.  That means that it can 
> arrange for incoming requests to be executed as "eraser".  If only the 
> permissions of the authenticated subject "eraser" are consulted, then 
> "creator" can delete files.  This is why "creator"'s permissions must be 
> consulted too.
> 
> 
>>Suggestion: What if the code which does the mapping to Subject is
>>privileged (codebase trust) and the principal in charge of reading the 
>>socket does not get a hold of this Subject ever and does not have access 
>>to it, and the JMX infra that does get a hold of the Subject, is also 
>>privileged (again, codebase trust and not principal based) then I don't 
>>see any problem in using the connected subject's privileges, what ever 
>>they may be.
>>So, the Subject associated with the security context when start() is 
>>called does not affect the actual privileges the connected subject gets.
> 
> 
> What you are saying is that it is possible to use this API in a way that 
> is secure.  But that is not enough.  It must also be *impossible* to 
> *exploit* the API in a way that breaks security.  The proposed semantics 
> allow such an exploit so they must not be implemented.
> 
> Regards,



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