dev@glassfish.java.net

Re: [Design Idea]About GLASSFISH-16998 and GLASSFISH-13006

From: Tang Yong <tangyong_at_cn.fujitsu.com>
Date: Thu, 12 Jul 2012 11:55:57 +0900

Dear Sahoo, Tom

> Thanks for looking into it. With this proposal, once the remote shell
>is enabled, the security issue described in the bug still remains. Can
>you think of any way to make the port secured such that only users
> authneticated using glassfish admin user name & password can access >
>the port.

Thanks your comment. Right, I forgot that a user can login/ssh/telnet
into the machine with gf remotely or execute asadmin command remotely.

So, I modified the proposal.

1. "Turn off" org.apache.felix.shell.remote bundle.
2. Provide a subcommand as following:

asadmin start-felixremoteshell --telnet.ip <ipvalue> --telnet.maxconn
  <maxconnvalue> --telnet.port <portvalue> --saveoptionfile <filepath>

1) the subcommand helps to set port value and also execute telnet
felix.shell.

2) after executing subcommand, in domain.xml, not write the following
contents for security.

 <jvm-options>-Dosgi.shell.telnet.port=<portvalue></jvm-options>
 <jvm-options>-Dosgi.shell.telnet.maxconn=<maxconnvalue></jvm-options>
 <jvm-options>-Dosgi.shell.telnet.ip=<ipvalue></jvm-options>

In addition, while Glassfish distribution/build, also not write the
above contents.

3) in saveoptionfile , contents are as following:
eg.
osgi.shell.telnet.ip = 127.0.0.1
osgi.shell.telnet.port = 6667
osgi.shell.telnet.maxconn = 1
adminusername = root
adminpassword = XXX

The saveoptionfile is saved in user.home directory for security.

"adminusername" and "adminpassword" are for avoiding inputing username
and password after for the first time authenticating successfully.

4) while executing subcommand,

  3.a if saveoptionfile does not exist or although exist, contents are
       not invalid(eg. having not "adminusername" and "adminpassword" ),
       let user to input gf admin username and password, and then, save
       the security port into saveoptionfile.

  3.b if not 3.a, firstly will use user.home/.asadminpass to compare to
       saveoptionfile, if not matching, the subcommand will let user to
       input gf admin username and password to validate; otherwise,
       enter into felix.shell.

Note1: The saveoptionfile needs to be saved in user.home directory,
thus, when a remote user logins and want to execute the subcommand,
he/she can not read the saveoptionfile unless he/she is owner of the
user.home.

Note2: in domain.xml, not record the felix.shell.remote-related options
in order to protect that some one can get the options from domain.xml
and use "telnet XXX YYY" to login felix shell.

--Best Regard!
--Tang

Sahoo wrote:
> Hi Tang,
>
> Thanks for looking into it. With this proposal, once the remote shell is
> enabled, the security issue described in the bug still remains. Can you
> think of any way to make the port secured such that only users
> authneticated using glassfish admin user name & password can access the
> port.
>
> Thanks,
> Sahoo
>
>> Dear Sahoo, Tom
>>
>> About GLASSFISH-16998 and GLASSFISH-13006, I have a design idea
>> and want to discuss with you.
>>
>> My design idea is as following:
>>
>> 1 "Turn off" org.apache.felix.shell.remote bundle
>> Just as Richard S. Hall said:
>>
>> "From an OSGi perspective, the way to administratively turn off a bundle
>> is to stop it or not deploy it. "
>>
>> I think that Stoping shell.remote bundle is a better way on the current
>> gf architecture.
>>
>> Because on the current gf's code, GlassFishActivator class and
>> GlassFishActivator.startPostStartupBundles() have not been existed, I
>> think that the better way is to modify OSGiGlassFishRuntimeBuilder.build
>> method and add the logic to stop org.apache.felix.shell.remote bundle
>> behind "framework.start()" .
>>
>> 2 provide a way to administratively turn on shell.remote bundle
>>
>> Just as said on GLASSFISH-13006, felix shell is also important not only
>> for framework developers(re-develop based gf), but also for OSGi app
>> developers.However, also need to consider people who are not interested
>> in OSGi. In addition, considering administrative and security aspects, I
>> think that:
>>
>> Supporting a admin cli command for turning on shell.remote bundle,
>> liking the following:
>>
>> asadmin start-felixremoteshell --telnet.port <portvalue> --portsavedfile
>> <filepath>
>>
>> About design of the command,
>> 1) --telnet.port is optional, if not inputing, gf will select an unused
>> port randomly.
>> 2) after executing the command, gf will display the port value on
>> os-related shell window in order to let the user to know the port.
>> 3) --portsavedfile is optional, if not inputing, gf will save the port
>> value on a file of "user.home" by means of enciphering the port value.
>> 4) when executing the command again, if user does not input port value,
>> gf will firstly read port value from the portsavedfile, and if can't
>> get the port value from the portsavedfile, then, executing the logic of
>> 1) and updating the portsavedfile.
>>
>> --Best Regard!
>> --Tang
>>
>
>
>