-------- Original Message --------
Subject: Re: request asarch review for deploy command enhancement in
GlassFish
From: Bill Shannon <bill.shannon_at_oracle.com>
To: Craig Perez <craig.perez_at_oracle.com>
CC: 吕宋平 <lvsongping_at_gmail.com>, dev_at_glassfish.java.net,
hong.hz.zhang_at_oracle.com
Date: Tuesday, May 28, 2013 5:40:39 PM
> Craig Perez wrote on 05/28/13 13:48:
>> 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.
> Good.
>
>>> 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.
> The server might be behind the firewall in the corporate intranet and
> the client might be outside the firewall somewhere on the internet.
> The server might be able to access other corporate resources that the
> client can't access because of the firewall.
>
>>>
>>>> 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.
> Limiting the URI types could be used to address both (A) and (B):
>
> $ asadmin set server.deployment.allowedUriTypes="http,file"
> (equivalent to the default, perhaps?)
>
> $ asadmin set server.deployment.allowedUriTypes="http"
> (don't allow file: URLs)
>
> $ asadmin set server.deployment.allowedUriTypes=""
> (don't allow anything, effectively disabling the deployuri command)
>
> Exact "dotted name" is TBD; the above is just an example.
>
[Craig] Please keep in mind that if the same level of permission is
needed to change the configuration remotely as to issue the command
remotely with URI then risk is still present.
>>>
>>>> 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?
> What additional restrictions would there be for this other location,
> and what software would be applying the restrictions?
>
> Do you view this as a "staging" area, with the application being
> copied to the usual location after being "verified" in some way?
[Craig] Yes that would be one option for what I was thinking, there
might be duplication of files to consider but that may already be issue
with multiple machine domain deployments already? The additional
restrictions are as as I mentioned above applied in their simplest form
by the OS/Kernel with file permissions, quotas, etc. and perhaps even a
potential for some virus scanning to be applied?
>
>>>> 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!
>>>
> This seems like a completely separate issue that could be its own
> one-pager.
>