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

Eamonn,

Thank you for your reply.
I will address it in more detail later.

Please consider what we actually require:

In our system, a high privileged user can do a lot of damage. Practically install and run arbitrary code.
The system, most of the time, does not require this privilge. A component which is a daemon (not a human) normally runs and does 'benign' stuff. We want to be able to use a daemon identity (Subject) which has low privilege. There is no problem if some of the code (including authenticator code) has codebase- based high privilege. We don't want to store sensitive credentials on the daemon.

In addition, one Mserver talks to other Mservers which talk to other components. We require the (public) credentials to propogate through to the end-point. Unfortunately, for reason unknown to me, the Subject class is final and its public credentials DO NOT serialize as they are transient (!).
We have potentially many connections so the method in which a Subject is passed as the delegate is inconvenient and does not (as is) fit our security model. We want to be able to reuse (or multiplex) connections, but pass in credentials when we delegate.

Regards,
Ron.

-----Original Message-----
From: Eamonn McManus [mailto:[email protected]] 
Sent: Friday, September 03, 2004 4:58 AM
To: Ron Vered
Cc: MX4J-Dev (E-mail); Bordet, Simone; Luis Miguel Alventosa
Subject: Re: [Mx4j-devel] 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 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