Craig Perez wrote on 05/23/2013 01:28 PM:
> My general comments follow Bill's concerns about accessing resources that the
> "client" itself would normally have access to or potentially use the
> "credentials" of the server to access the resource on behalf of the client.
Does that imply that you think the concern is not a risk, or is a manageable risk?
> Beyond that I think there are a few other items to consider:
>
> A) An option to disable the deployuri command completely should the
> administrator be concerned
Do you think we need a special option just to control this, or can it wait until
we have a more general permission framework and support for roles?
> B) An option to limit the URI types that would be allowed
This seems reasonable. An attribute or property set with "asadmin set" would
probably be good enough.
> C) Allow for specification of a "sandbox" area use as the download location to
> better control permissions, ownership, quotas, disk space, etc.
Uploaded apps are already stored in a special area, is that not good enough?
> D) Allow for the possibility to include hooks for virus scanners or other
> intrusion detection software
Probably a good idea for a product! If we were to add a hook for that it should
apply to all submitted apps.
> Thanks, -Craig
>
> -------- Original Message --------
> Subject: Re: request asarch review for deploy command enhancement in GlassFish
> From: 吕宋平 <lvsongping_at_gmail.com>
> To: Bill Shannon <bill.shannon_at_oracle.com>
> CC: hong.hz.zhang_at_oracle.com, dev_at_glassfish.java.net
> Date: Thursday, May 23, 2013 6:45:51 AM
>> Hi, Bill:
>>
>> 2013/5/23 Bill Shannon <bill.shannon_at_oracle.com <mailto:bill.shannon_at_oracle.com>>
>>
>> 吕宋平 wrote on 05/22/13 01:18:
>>>
>>> Hi, Bill:
>>>
>>> Cc: asarch_ww members, Security team:
>>>
>>> Yes, the one pager which have been approved to the wiki didn't take care
>>> such security problem. The change can cause the server to access files
>>> and network resources that the administrator might not be able to access
>>> directly. But I think this security issue is only happen in the file://
>>> syntax.
>>>
>>> I think both of the administrator and server can access the source file
>>> and network resource when it comes to the http:// syntax and ftp://
>>> syntax, so I think it is no need to take care the security into
>>> consideration when it comes to these situation.
>>>
>> The ability to access it might depend on what IP address is being used,
>> which will be different between the client and the server.
>>
>> You also have to be sure that the server isn't going to use any HTTP
>> authentication when accessing the resource since the client might not
>> have permission to use that authentication information stored on the server.
>> Yes, I will. I think the operation about download the remote resource
>> will be based on the situation that the client have the permission to
>> access it without any authentication information stored on the server.
>> Because it's hard for the glassfish client to process such a situation.
>>>
>>> [For Example]
>>>
>>> A: glassfish server
>>>
>>> B: glassfish server
>>>
>>> C: ftp server
>>>
>>> D: http server
>>>
>>> (1)Deploy the application from the machine B(Regard A as a admin client
>>> side, Regard B as a server side)
>>>
>>> Execute the command line on the machine A as “asadmin deployuri --host
>>> host_address_B file:///etc/appname”, It's true that administrator A
>>> can't access the application exist on the machine B, but the application
>>> will be deployed to the B through this command, the administrator of A
>>> only know the application name but don't know what exist in the
>>> application. I don't think it will affect so much to the security.
>>>
>>> (2)Deploy the application from the machine C
>>>
>>> Execute the command line on the machine A as “asadmin
>>> deployuriftp://username:password@host_C:21/appname
>>> <ftp://username:password@host_c/appname>”, I think both of the
>>> administrator and server side on the machine A can access the
>>> application exist on the ftp server C. I think it's no need to take the
>>> security into consideration here because both of the administrator and
>>> server can access the source file.
>>>
>>> (3)Deploy the application from the machine D
>>>
>>> Execute the command line on the machine A as “asadmin
>>> deployurihttp://host_address_D/appname <http://host_address_d/appname>”,
>>> I think both of the administrator and server side on the machine A can
>>> access the application exist on the http server D. I think it's no need
>>> to take the security into consideration here because both of the
>>> administrator and server can access the source file.
>>>
>>> >Perhaps I'm being paranoid but I'd like to see some discussion about the security implications of
>>> being able to tell >the server to access resources that you might not be
>>> able to access directly. Certainly the check for filename >extensions
>>> will help, but you still need to be sure to handle cases such as
>>> "file:///etc/passwd?name=foo.ear".
>>> I'm not sure about the file:// syntax "file:///etc/passwd?name=foo.ear".
>>> Could you clarify about this?
>> If you just look at the end of the string to see if it ends with ".ear",
>> you'll think that name is ok. But it's not. It actually accesses the
>> /etc/passwd file.
>> Ok, I got it!
>>
>>> I don't think the change will affect the security too much. So I hopeyou
>>> and the security team's will list more questions and discussion here.
>> Yes, I really want to hear more from our security experts.
>> Ok, let's wait for the security to list some suggestion about this!
>>
>> Thanks a lot!
>> -Jeremy
>