Major Description
Why ?
JMX is inherently insecure and it's usage can allow local non-root user, as they can access port 9999, to escalate their privileges.
How? Solution summary
Set up JMX authentication: local users won't know which password to use (password file only readable to james user).
Generate JMX credentials on the fly so that we can activate JMX authentication by default without shipping some default credentials for it.
How? Solution details
Try the `-Dcom.sun.management.jmxremote.password.file=/root/conf/jmxremote.password` JVM parameter.
Content of `jmxremote.password``:
admin magicpass
Modify the CLI code to take an optional username, optional password:
- [ ] if username and password is unspecified, then use none
- [ ] if only password is specified, default to `james-admin` username.
- [ ] if only username is specified, prompt the user to enter a password.
java -cp /root/resources:/root/classes:/root/libs/* org.apache.james.cli.ServerCmd -username james-admin -password p4$$w0rD
Specify the configured username and password when establishing the JMX connection.
BONUS: if no username / password is specified, attempt to read `conf/jmxremote.password` and see its content to use the configured username + password. Default to none only if this file cannot be found. This ensure no changes in the docker containers james-cli script.
BONUS x 2: When James starts, generate randomly `jmxremote.password` (fixed username, default password) if none exists. This makes the default package of james secure (no usage of hardcoded credential, a user do not need to change something to make this secure). Plan a system property to disable this behaviour `-Djames.jmx.credential.generation=true|false`.
- [ ] Set up JMX authentication in the default applications with a DUMMY passwor (`jmxremote.password` only readable to the james user)
- [ ] Document setting up authentication for JMX. Explain in security guidelines that JMX auth can prevent privilege escalation.
