Yeahs, it makes sense to me. One additional thing about the password that comes to my mind, is the ability to integrate the change of password with ssh (when using keyboard interactive, the ssh server can ask the user for a password change before actually logging in, so that changing the password would also work if using bin/start and bin/client).
Anyway, those changes are quite important and should be done in minor / major releases but maybe not micro ones. 2014-07-18 9:28 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi Guillaume, > > I guess you mean default karaf/karaf. > > Why not doing a kind of "unix" like bootstrap like the root user: we can > consider the karaf user as the root user, so mandatory. Why not defining an > empty password by default and at bootstrap, if the password is empty (when > starting with bin/karaf), prompt for a password. > > I would propose two steps: > - first to "fix" the security hole, comment the key and document how to > enable/change it (it will be included in next releases) > - second, we provide the ssh:key-gen/key-add and passwd commands/MBeans > operations + the prompt of password if the karaf password is empty. > > WDYT ? > > Regards > JB > > > On 07/18/2014 09:21 AM, Guillaume Nodet wrote: > >> In the same line, shouldn't we remove the default user then ? >> And add command or maybe prompt for credentials at first boot ? >> >> And what about child containers ? Should credentials be propagated >> somehow ? >> >> >> 2014-07-17 21:44 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: >> >> Hi all, >>> >>> Following a discussion that we had with Christian, I would like to raise >>> a >>> concern. >>> >>> Now, on Karaf 2.x/3.x/4.x, the JMX layer is secure using RBAC. The >>> MBeanServerBuilder is enabled by default, meaning that it's not possible >>> to >>> locally connect to the MBean server. >>> I think it's good and secure. >>> >>> However, on the other hand, we have a key enabled by default (in >>> etc/keys.properties) and used by default by bin/client. >>> So it means that any user that download a Karaf distribution can connect >>> to any Karaf runtimes by default. >>> On one hand we have a very secure JMX layer (even for local connection), >>> but on the other hand, bin/client can connect to any Karaf running >>> instance >>> (so not very secure). >>> >>> I would like to propose the following: >>> - in etc/keys.properties, we should comment out the default key. We can >>> document how to enable it and how to change the keys. >>> - in bin/client, we should be able to specify a key that we want to use. >>> >>> WDYT ? >>> >>> I already created some Jira about the keys: >>> - KARAF-2786: I would change this one by comment out the default key >>> - KARAF-2836 to allow to specify multiple keys for an user in >>> etc/keys.properties >>> - KARAF-2787 to allow to specify the key to bin/client >>> >>> Thanks, >>> Regards >>> JB >>> -- >>> Jean-Baptiste Onofré >>> jbono...@apache.org >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >>> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
