On 5/28/2013 4:48 PM, Craig Perez wrote:
> Hi Bill, Jeremy, some additional remarks on my part below... 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: Craig Perez <craig.perez_at_oracle.com>, dev_at_glassfish.java.net,
> hong.hz.zhang_at_oracle.com
> Date: Monday, May 27, 2013 7:56:13 AM
>>
>> 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
>> <mailto: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?
>>
>
> [Craig] I would expect the risk to be manageable with some reasonable
> controls on the URI handling similar to remarks being discussed for
> options below.
>
>> 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.
>>
>
> [Craig] An example might be using SSL, the connection from GlassFish
> may be trusted for download from the source where the "client" itself
> may not be able to establish an SSL connection to the source.
>
>>
>>> 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 thinkwe can wait until we have a more general permission
>> framework and support for roles, what do you think?
>>
>
> [Craig] A simple approach ahead of a more general role based framework
> would probably help sooth the concerns of those that consider the
> secure production environment as their target. Would there be some way
> of having a local command that controls disablement and/or some of the
> config settings? Perhaps just removing a module or updating
> configuration that is not domain specific? The reverse could also be
> considered, add a module or non-domain config to enable deploy with
> URI which of course is not as developer friendly?
>
>>
>>> 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”?
>>
>
> [Craig] I'm not sure I understand what is being asked. Is this related
> to where configuration lives or what mechanism is used to change options.
>
>>
>>> 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?
>>
>
> [Craig] Hong may have more comment/experience on the current
> application deployment folder(s) usage. I was thinking of a place
> outside the domain that could have more restrictions in place. The
> current folder or new folder as suggested may be fine, I thought I
> recall some mention of using the /tmp area?
The current location to hold uploaded applications is within the domain:
domains/<domain_dir>/applications/__internal/<app_name>/
>
>>> 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> <mailto:lvsongping_at_gmail.com>
>>> To: Bill Shannon <bill.shannon_at_oracle.com>
>>> <mailto:bill.shannon_at_oracle.com>
>>> CC: hong.hz.zhang_at_oracle.com <mailto:hong.hz.zhang_at_oracle.com>,
>>> dev_at_glassfish.java.net <mailto: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
>>>
>>
>>
>