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

All,

I think it's OK in general if codebase- privileged code does some privileged operation which is internal to it but otherwise was started by a less privileged Subject. Otherwise there would not be away to do this in JAAS at all. For example, a thread running with a less privileged Subject does a logout(). The logout method may do internal sensitive stuff, but its OK because the logout codebase is privileged and the only outcome the Subject can gain is allowed to it.

In the same manner, if some subject A initiated an operation, where the operation's codebase is privileged, and A cannot make it so the operation will eventually result in some privileged operation, part of all the privileged operations A is not allowed to execute, being executed indirectly with A's deliberate intention, AND A cannot learn any information of some sensitive input/output associated with such privileged operation and cannot alter this sensitive input/output, then you are perfectly OK.

There is an important difference between initiating an operation to performing the operation, for example, if a connector server is initiated by A, A may never see or control any of the information going through, unless of course the connector server, for example, is not privileged as well or has holes that allow A to peek or alter data going through.

To summarize, I think unless A can directly cause an illicit desired outcome, peek or alter data flow, its OK for A to be less privileged.

Regards,
Ron.

-----Original Message-----
From: Eamonn McManus [mailto:[email protected]] 
Sent: Friday, September 03, 2004 9:13 AM
To: Bordet, Simone
Cc: Ron Vered; MX4J-Dev (E-mail); Luis Miguel Alventosa
Subject: Re: [Mx4j-devel] RE: [Mx4j-user] RE: mx4j-Bugs-969175: Security and delegation


Bordet, Simone wrote:
> Hi Eamonn,
>>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.
> 
> I still haven't understood if you think the alternative implementation
 > has a security hole or not. I think it has not.

I think it has.

> Eamonn, I have understood your example where a connector can return
 > non-authenticated users. But I think it does not demonstrate any  > security hole, and I am still not convinced.

I don't get you.  Usually, jmx-remote.jar (or whatever the MX4J 
equivalent is) would be installed with AllPermission, right?  Certainly 
when it lives in J2SE this is the case.  So, if I have a setup where 
this is the case, and where some other code "creator" has 
SocketPermission but no other permission, and where there is a Subject 
"eraser" that has some other permissions, and where there is an MBean 
that needs those permissions, then "creator" can invoke that MBean 
without having the requisite permissions.  Therefore the security model 
is violated.  It doesn't matter that this might not be a very usual 
configuration.  It doesn't matter that you *can* set things up securely. 
  The point is that you are providing a library that could in some 
circumstances allow people to subvert the security model.  That is bad.

The fact that this is not the default behaviour does change things.  If 
the new behaviour is only turned on if you set a system property, and if 
you document the security risk of setting the property, then there 
should not be a problem.  If the new behaviour is turned on by supplying 
a property in the environment Map when you create the connector server, 
then there *is* a problem, since evil code can supply that property.  I 
think that the SubjectDelegationPermission solution is much cleaner than 
setting a system property.

Just to be clear, the change whereby the authenticated Subject does not 
need specific permissions (other than SubjectDelegationPermission) if it 
delegates to another Subject is all right, and is what the RI already 
does.  You do not need a special switch to turn that on.  What's 
dangerous is ignoring the permissions of the connector server's creator.

Concerning the rest of your message, I agree with the contents of the 
policy files you show.  The fact that the "Alternate implementation" 
allows simpler configuration is irrelevant since it also subverts 
security.  The "Proposed implementation" is not materially more 
difficult, since if you do want the behaviour of the "Alternate 
implementation" you only have to add one line to the grant for 
"jmxconnectorserver.jar":

     permission SubjectDelegationPermission "*";

-- 
Éamonn

> Also, I'm seeing the issue more from the point of view of the person 
> that has to make the system work. The assumption is that the system 
> must allow a certain principal to delete files. The assumption is that 
> no codebase is trusted: it must have the least set of permissions 
> possible.
> 
> The only policy file that allow a non-trusted "jmxconnectorserver.jar" 
> to delete files is the first, the default implementation. The proposed 
> solution buys nothing for one more permission.
> 
> But sure we must discuss this better.
> 
> In almost-policy-file-syntax:
> 
> Current implementation:
> ~~~~~~~~~~~~~~~~~~~~~~~
> 
> grant codebase "jmxconnectorserver.jar"
> {
>    permission SocketPermission "localhost","listen";
>    permission SocketPermission "*:1024-","accept";
> 
>    permission FilePermission "<<ALL FILES>>","delete";
> };
> 
> grant principal "eraser"
> {
>    permission MBeanPermission "com.acme.Eraser","invoke";
>    permission FilePermission "<<ALL FILES>>","delete";
> };
> 
> 
> Alternate implementation:
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> grant codebase "jmxconnectorserver.jar"
> {
>    permission SocketPermission "localhost","listen";
>    permission SocketPermission "*:1024-","accept";
> };
> 
> grant principal "eraser"
> {
>    permission MBeanPermission "com.acme.Eraser","invoke";
>    permission FilePermission "<<ALL FILES>>","delete";
> };
> 
> Proposed implementation:
> ~~~~~~~~~~~~~~~~~~~~~~~~
> 
> grant codebase "jmxconnectorserver.jar"
> {
>    permission SocketPermission "localhost","listen";
>    permission SocketPermission "*:1024-","accept";
> 
>    permission SubjectDelegationPermission "eraser";
> };
> 
> grant principal "eraser"
> {
>    permission MBeanPermission "com.acme.Eraser","invoke";
>    permission FilePermission "<<ALL FILES>>","delete";
> };


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