Good idea for the password changes before logging.
And agree for these changes in major releases. That's why I proposed two
steps: the comment of key on next micro release, the "big changes" ;)
for next major one.
Regards
JB
On 07/18/2014 10:10 AM, Guillaume Nodet wrote:
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é <[email protected]>:
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é <[email protected]>:
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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
