Hi, Bill, Craig:
Sorry about reply the mail later! Here’s some of my comments:
2013/5/24 Bill Shannon <bill.shannon_at_oracle.com>
> 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?
>
> I think the original syntax of mine that the “client” itself would
> normally have access to.
>
> I am not sure how to potentially use the "credentials" of the server to
> access the resource on behalf of the client now.
> But if we decided to take the second syntax about the security about
> “client”, I will do some investigation later.
>
> 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?
> I think we can wait until we have a more general permission framework and
> support for roles, what do you think?
>
> 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.
> Ok, I got it! How will support an option to limit the URI types which
> called --types instead of support an attribute or property set with
> “asadmin set”?
>
> 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?
> Shall we need to make some external file directories which will be
> regarded as download location? If it is needed, How about creating a file
> named as
> “download_file”which will be created under the directory
> of domain/domain1?
>
> 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.
> Yes, it seems a good idea about this, it seems hard but I will try whether
> I can found some hooks like this!
>
> Thanks, -Craig
>
> -------- Original Message --------
> Subject: Re: request asarch review for deploy command enhancement in
> GlassFish
> From: 吕宋平 <lvsongping_at_gmail.com> <lvsongping_at_gmail.com>
> To: Bill Shannon <bill.shannon_at_oracle.com> <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>
>
>> 吕宋平 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 deployuri
>> ftp://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 deployuri
>> http://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 hope you
>> 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
>
>
>
>