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