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