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