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,
-- 
Éamonn

> Regards,
> Ron.
> 
>     -----Original Message-----
>     *From:* Eamonn McManus [mailto:[email protected]]
>     *Sent:* Thu 9/2/2004 4:05 AM
>     *To:* Ron Vered
>     *Cc:* MX4J-Dev (E-mail); Bordet, Simone;
>     [email protected]
>     *Subject:* Re: [Mx4j-user] RE: mx4j-Bugs-969175: Security and delegation
> 
>     Ron,
> 
>     I get the feeling we are talking at cross-purposes here.  There is a way
>     in which the JMX Remote API can be used by malicious code to gain
>     privilege if it does not make the checks that the RI makes.  This could
>     be code that you didn't even know was going to use that API.  All you
>     know is that you assumed that if you granted an applet (say) the ability
>     to open a server socket on port 2000 then it would be able to open a
>     server socket on port 2000, but it would not be able to delete files,
>     even if a principal "superuser" in your system does have the ability to
>     delete files.  But, in fact the code takes advantage of its permission
>     to create a JMXConnectorServer in such a way that any connection to that
>     server gets authenticated as "superuser".  The applet, or anyone else,
>     connects to the JMXConnectorServer and accesses the DeleteFilesMBean. If
>     you don't consult the permissions of the entity that created the
>     connector server, then you will execute all MBean operations as
>     "superuser" and bang, your applet can delete files.
> 
>     --
>     Éamonn
> 
>     Ron Vered wrote:
>      > 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,
> 
> ------------------------------------------------------------------------------
> 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.
> ====================================================
> 
> N¬HS^µéšŠX¬²š'²ŠÞu¼žnZ 
> ‰Å¨®K!¢‘QBZ½¡'µêé®+'auëÞ–Š^®Ú(–Áž·*.­úÞyÊ)ʇÁžlº 
> ‰Å¨®K!¢Ÿ5¶‡ZÊm§ÿÚvÊ,vw(›ö‰ÐÓŽÚ–Z‰ÐÓÍ<¢–'$3#ºÇ«™¨¥Šx%ŠËLLjî±êåŠËl²‹«qç讧zØm¶›?þX¬¶Ë(º·~Šàzw­þX¬¶ÏåŠËbú?›#ºÇ«


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