On 07/12/2012 08:27 PM, Tom Mueller wrote:
> Agreed. But with Ancoron's felix command it is now possible to use the
> OSGi shell without having to open the security hole. That's what's
> really nice about this.
>
> Tom
>
Well... guess what?
It was so easy:
* copy MultimodeCommand
* modify prompt
* introduce remote command prefix
Usually my code is in Apache 2 license, but as I forked off some code
here I complied to use the CDDL + GPL 1.1.
However, it would have been much much easier with a MultimodeCommand
that is a bit more open for extensions so that I just have to provide a
custom prompt and a custom command execution so that I can re-use the
infrastructure and just have to extend it instead of copying code.
Attached a very first little patch for this extensibility approach.
Code:
https://github.com/ancoron/gf-samples/tree/master/asadmin-ext/felix-shell-interactive
Snapshot binary:
https://oss.sonatype.org/content/repositories/snapshots/org/ancoron/glassfish/asadmin/org.ancoron.glassfish.asadmin.felix.shell.interactive/1.0.6-SNAPSHOT/org.ancoron.glassfish.asadmin.felix.shell.interactive-1.0.6-20120712.231354-1.jar
Installation:
* put it in .../glassfish/lib/asadmin/
Example:
glassfish$ ./bin/asadmin -t felix-shell
Use "exit" to exit and "help" for online help.
felix> help
bundlelevel
cd
find
headers
help
inspect
install
log
ps
refresh
resolve
scr
shutdown
start
startlevel
stop
sysprop
uninstall
update
version
Use 'help <command-name>' for more information.
felix> find felix.shell
START LEVEL 3
ID State Level Name
[ 160] [Active ] [ 3] Apache Felix Shell Service (1.4.1)
[ 208] [Installed ] [ 1] Apache Felix Shell TUI (1.4.1)
[ 243] [Installed ] [ 1] Apache Felix Remote Shell (1.1.2)
[ 263] [Active ] [ 1] GlassFish asadmin sub-command that executes
any Felix Shell Command (1.0.6.SNAPSHOT)
felix> inspect
Too few arguments.
inspect (package|bundle|fragment|service) (capability|requirement) [<id>
...]
felix> inspect s c 263
GlassFish asadmin sub-command that executes any Felix Shell Command
(263) provides services:
--------------------------------------------------------------------------------------------
Nothing
felix> inspect p r 263
org.ancoron.glassfish.asadmin.felix.shell [263] imports packages:
-----------------------------------------------------------------
org.osgi.framework; version=1.6.0 -> org.apache.felix.framework [0]
org.apache.felix.shell; version=1.0.0 -> org.apache.felix.shell [160]
org.jvnet.hk2.component; version=1.1.14 ->
org.glassfish.hk2.auto-depends [188]
org.jvnet.hk2.annotations; version=1.1.14 ->
org.glassfish.hk2.auto-depends [188]
com.sun.hk2.component; version=1.1.14 -> org.glassfish.hk2.auto-depends
[188]
org.glassfish.api; version=3.1.2 ->
org.glassfish.main.common.glassfish-api [202]
org.glassfish.api.admin; version=3.1.2 ->
org.glassfish.main.common.glassfish-api [202]
org.ancoron.glassfish.asadmin.utils; version=1.0.5.SNAPSHOT ->
org.ancoron.glassfish.asadmin.org.ancoron.glassfish.asadmin.utils [260]
felix> exit
glassfish$
Cheers,
Ancoron
>
> On 7/12/2012 12:27 PM, Sahoo wrote:
>> Tom,
>>
>> What I meant to say is that once a user has been authorised to execute a
>> command, not much we can do. e.g., one could use admin console to enable
>> debugging which opens a port which bypasses any kind of security. Admin
>> console does not prevent that kind of configuration AFAIK. Similarly,
>> administrator can turn of security manager. We should view an
>> administrator enabling felix remote shell as one such action.
>>
>> Thanks,
>> Sahoo
>>
>> On Thursday 12 July 2012 09:25 PM, Tom Mueller wrote:
>>> Sahoo,
>>> I don't understand this reasoning.
>>>
>>> As long as the administrator is using asadmin to run the felix shell
>>> commands, security is fine. But as soon as the admin provisions the
>>> remote shell on a port, then anyone can connect to that port an access
>>> the shell (since there is no authentication on the remote shell). Having
>>> that port open is a security risk no matter how it is configured.
>>>
>>> I really like Ancoron's "felilx" command that enables one to run the
>>> OSGi shell commands. IMHO, this could eliminate the need to ever enable
>>> the remote shell on a port for typical uses.
>>>
>>> Tom
>>>
>>>
>>> On 7/12/2012 10:25 AM, Sahoo wrote:
>>>> On Thursday 12 July 2012 08:01 AM, 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.
>>>> Since the asadmin command can be executed by someone with admin
>>>> privileges, we won't consider it a security risk if admin provisions the
>>>> remote shell using an asadmin command. So, I agree with what's being
>>>> said by Ancoron.
>>>>>> 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.
>>>>>
>>>> Same argument holds good here as well.
>>>>
>>>> Sahoo