Hi Luciferis
Thanks your detailed reply very much!
Firstly, let us wait for sahoo's idea again.
> If you really want a secure port to access the OSGi shell you should
> take a look at Apache Karaf as they have an SSH shell:
>
> http://felix.apache.org/site/42-remote-console.html
OK, I will see it. Previously,I have also considered SSH shell and
however, I think that how to modify and extend the current code more
easily should be most important. Do it step by step.
> 1.) why saving the port into a file? Do you think it is too hard for a
> user to read the port number?
Just on a thread which has been sent, I gave a explanation.
--Best Regard
--Tang
Ancoron Luciferis wrote:
> On 07/12/2012 02:27 AM, Tang Yong wrote:
>> Hi Luciferis
>> CC: sahoo
>>
>>> This way we just have to manage GlassFish security and yet have the
>>> ability to execute every command that is registered to the Felix>shell,
>> I have seen your implementation and indeed it is a different way of
>> handling the issue and I learned a lot. I have some comments about
>> security as following:
>>
>> 1 if a user firstly used the sub-command to install remote shell, then
>> enable the telnet, whether the same problem exists or not?
>
> In theory yes, in practice in my environments no-one without sudo-rights
> is going to accomplish that, since I prefer to run anything in its own
> "sandbox" and use system-level security as much as possible.
>
> If I would go and deny e.g. the "install" shell command I would likely
> receive complains about that immediately from other users. The main
> thing is that you have to distinguish between the coded application (as
> by the developer), the "deployer" (which may configure the application
> for the runtime environment) and the administrator which configures the
> runtime environment including JVM parameters and OS
> configuration/security. As I (as a developer) don't know what others may
> want to do with my code or the binary I prefer to leave the security
> part to the other roles.
>
> Going one step further you could activate the SecurityManager and
> white-list directories/files and/or black-list operations. This can be
> managed with fragments to existing bundles and is a way to secure the
> environment within its boundaries, although quite costly in terms of
> time investment to get the concept right and not shooting yourself in
> the foot while keeping the configuration as strict as possible.
>
>> 2 even if the user does not install remote shell, if he/she used the
>> sub-command to install/update/delete gf-managed bundles, then, security
>> hole may be still exist.
>
> The main problem is: whatever you try to deny from within your code or
> with configuration, as long as someone can write files all that effort
> will be futile.
>
>> What I understood to secured port has two means:
>> 1) protect gf and user-defined app/bundle from attacking
>> 2) enable/disable remote shell to switch between users with different
>> requirements
>
> If you really want a secure port to access the OSGi shell you should
> take a look at Apache Karaf as they have an SSH shell:
>
> http://felix.apache.org/site/42-remote-console.html
>
> That would be something worth porting to GlassFish, I think. And going
> further, you could re-use your company-wide LDAP server for
> authentication and implement auditing to see who did what.
>
> So your suggestion with the extra asadmin sub-command goes into the
> right direction. But please keep in mind to add an option for the
> interface to bind the port to. E.g. I currently prefer IPv6 link local
> "::1" instead of "localhost", because you can easily point "localhost"
> to a public interface.
>
> Some other notes:
> 1.) why saving the port into a file? Do you think it is too hard for a
> user to read the port number?
>
> 2.) enciphering something doesn't help much as it's just obfuscation.
> Better secure your files by the means of the operating system.
>
> 3.) What about the "stop-felixremoteshell" command?
>
> But in the end I think as the remote shell is meant for developers and
> not for day-to-day system administration it is fine as it is. For a more
> advanced remote shell GlassFish would really need a bridge between OSGi
> commands and asadmin sub-commands in a single environment that can be
> secured properly. An SSH shell that can handle authentication is
> probably much better suited here - best with keys, not passwords. Also
> it is important that there are options to handle script kiddies
> properly, e.g. basics like rate-limit command execution and/or
> authentication requests and connection attempts - doing all this in Java
> might be counter-productive.
>
> Cheers,
>
> Ancoron
>
> P.S.: sorry for that long post
>
>> --Best Regard!
>> --Tang
>>
>> Ancoron Luciferis wrote:
>>> Hi together,
>>>
>>> I just did a quite different way of handling this issue and still have
>>> every Felix shell command (whether from upstream or custom ones) at my
>>> hands:
>>>
>>> 1.) don't deploy/start the remote shell
>>> 2.) provide a simple asadmin sub-command that acts as a bridge between
>>> the GlassFish administration interface and the Felix Shell
>>>
>>> This way we just have to manage GlassFish security and yet have the
>>> ability to execute every command that is registered to the Felix shell,
>>> like this (gogo version - standard):
>>>
>>> $ ./bin/asadmin -t felix frameworklevel
>>> Level is 3
>>>
>>> ...or with the felix shell instead of gogo:
>>>
>>> $ ./bin/asadmin -t felix startlevel
>>> Level 3
>>>
>>> ...it allows as many arguments as you like:
>>>
>>> $ ./bin/asadmin -t felix find weld
>>> START LEVEL 3
>>> ID State Level Name
>>> [ 14] [Active ] [ 1] Weld integration for glassfish (3.1.2)
>>> [ 143] [Resolved ] [ 1]
>>> org.glassfish.main.web.weld-integration-fragment
>>> [ 193] [Resolved ] [ 1] Weld OSGi Bundle (1.1.4.Final)
>>>
>>> ...
>>>
>>> I've just pushed the latest code and did a small release for this artifact.
>>>
>>> You can get it here (it doesn't require any additional stuff but needs
>>> GlassFish 3.1.2 at least - OSGi core 4.3):
>>>
>>> https://oss.sonatype.org/content/repositories/releases/org/ancoron/glassfish/asadmin/org.ancoron.glassfish.asadmin.felix.shell/1.0.5/org.ancoron.glassfish.asadmin.felix.shell-1.0.5.jar
>>>
>>> ...the code is here:
>>>
>>> https://github.com/ancoron/gf-samples/tree/master/asadmin-ext/felix-shell
>>>
>>>
>>> Cheers,
>>>
>>> Ancoron
>>>
>>>
>>> On 07/11/2012 05:09 PM, 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
>>>>>
>>>
>>>
>>
>
>
>