[ 
https://issues.apache.org/jira/browse/KARAF-5330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16208206#comment-16208206
 ] 

Guillaume Nodet commented on KARAF-5330:
----------------------------------------

The issue KARAF-5427 should help. It should be included in 4.2.0.
That said, I'll give it a try, as the console user should be the one used by 
the security manager, so all permissions configured for that user should be 
applied on code running from the console.


> Require a specific role to access the SSH console
> -------------------------------------------------
>
>                 Key: KARAF-5330
>                 URL: https://issues.apache.org/jira/browse/KARAF-5330
>             Project: Karaf
>          Issue Type: Bug
>          Components: karaf-security, karaf-shell
>            Reporter: Tom Quarendon
>            Assignee: Guillaume Nodet
>             Fix For: 4.2.0, 4.0.10, 4.1.3
>
>
> The shell:cat command has no access control list associated with it in the 
> default configuration.
> The same is true of the "shell:ls" command. There may be other shell: 
> commands too that can provide filesystem access. I don't know whether cd, pwd 
> for example should be secured. "tac" most certainly should.
> This means that any user that can access the ssh console can navigate the 
> filesystem, reading and writing files as they like.
> For example, given the default configuration, if I have a "normal" user and 
> can therefore access the console, I can use shell commands to find our or 
> guess the location of the karaf install (shell:pwd will do that), then cat 
> the contents of the etc/users.properties file and find out all users 
> passwords (in the default configuration the passwords are in plain text). I 
> can also cat the etc/host.key file which would seem undesirable. 
> tac clearly would be a very dangerous command to have access to. It seems 
> likely that I could subvert many things by just writing directly to 
> configuration files using tac. I could, for example, change, or at least 
> invalidate the admin password by rewriting the users.properties file.
> All in all this feels like a major issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to