Add SALT envar for Security.salt setting, with special handling

[UFOSmuggler]

This adds the SALT envar to the image, to control the Security.salt setting.

It took a bit of digging to figure out if Security.salt does anything anymore, but it turns out it at least is used in session handling by CakePHP. I discovered that if I allowed a load balanced HA MISP deployment to have diverged Security.salt values I would get CSRF issues frequently. If I then converged the values, they would go away.

I wanted to be able to have each MISP instance in the HA deployment generate its own identical configs using this project's image, which is currently not possible unless I do something like use EFS to share app/Config between the containers, which leads to other issues such as race conditions with which instance is editing updating the config. For this reason I am adding the SALT envar.

MISP will by default auto-generate a value if the value in the config.php file is blank, but not if the line is absent from the config.php file, in which case it just shits the bed.

The current state of the MISP/misp-docker image is to just set it to "" (blank) in the config file if unset. This leverages MISP internal functionality to rewrite the config file with a nice random value.

Adding this as an envar means that if the envar is blank, it will auto-generate a new value every container start, which isn't great.

As a result, I added a new parameter to the envar json structure called blank_protection which will do nothing if the envar value is blank. In combination with the existing blank setting of the unset value, this leads to the following:

SALT=: If unset in config.php, make it blank, otherwise leave it alone. MISP will see the blank and auto-generate a nice value.
SALT=1234: Always set salt to 1234
#SALT=: Equivalent to uncommented blank

The default behaviour is unchanged, and existing salt values will be left alone.

[UFOSmuggler]

Related to #384

[ostefano]

Not sure from here whether it gets autogenerated each time we start the container?
What happens to redis persisted sessions?

[UFOSmuggler]

if we have SALT= as blank, what happens is:

1. entrypoint starts, a bunch of stuff happens
2. eventually we run init_minimum_config in configure_misp.sh which will add the Security.salt configuration directive as blank by setting the default from minimum_config.defaults.json, only if it does not already exist:

  "Security.salt": {
    "default_value": "",
    "command_args": "-f"
  },

3. straight after this configure_misp.sh runs init_configuration which does the new "set Security.salt to the SALT envar, if the envar is not blank". does nothing because it's blank.
4. MISP starts, sees a blank Security.salt and generates one, updating the config.

on subsequent container starts, 2 won't run because Security.salt exists, leaving the existing autogenerated salt alone, 3 is still blank so does nothing, and 4 sees a good value so does nothing.

davidz@ocp:~/stuff/misp-docker$ sudo grep salt configs/config.php
davidz@ocp:~/stuff/misp-docker$ grep SALT .env
SALT=
davidz@ocp:~/stuff/misp-docker$ docker compose up -d 2>/dev/null
davidz@ocp:~/stuff/misp-docker$ sudo grep salt configs/config.php
davidz@ocp:~/stuff/misp-docker$ sudo grep salt configs/config.php
    'salt' => 'P#fxQ3f*o9lXUBY_pC*U-vQtwiK1?8WG',
davidz@ocp:~/stuff/misp-docker$ docker compose restart misp-core 2>/dev/null
davidz@ocp:~/stuff/misp-docker$ sudo grep salt configs/config.php
    'salt' => 'P#fxQ3f*o9lXUBY_pC*U-vQtwiK1?8WG',

If SALT=blah, 1 and 2 still happens, 3 sets Security.salt to blah, 4 sees a good value so nothing happens.

[UFOSmuggler]

redis (or whatever session method is used) persisted stuff will only invalidate if the salt changes, which it shouldn't unless you delete it from the config, or set SALT to a value.