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