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