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