software/ors-amarisoft: enb/generic: Protect from buildout code injection
We currently have at least the following problem:
1. a malfored shared instance reference leads to instantiation failure and
potential buildout code injection. For example if reference of shared
instance contains space then buildout fails with something like
zc.buildout.configparser.ParsingError: File contains parsing errors: .../instance-enb.cfg
[line 45]: '[promise-testing partition 0.RU-sdr-busy]\n'
since, when requesting, it is possible to use arbitrary characters for
references, including newline, it also opens the door for code injection attacks.
2. we currently use `json` directive of slapos.recipe.template e.g. as
extra-context =
json iru_dict {{ rulib.iru_dict | tojson }}
this also potentially leads to instantiation failure if JSON(rulib.iru_dict)
contains buildout control characters.
Solve this problems.
For 1 we develop "buildout encoding" that encodes arbitrary string into form
that is safe to be used as a name of buildout section. This encoding never fails
and does not loose information, which means it is safe to be applied
unconditionanly and there is no chance for two string inputs to result in the
same encoded form. The encoding also has practical property that it leaves most
of the strings, that we use in our buildot profiles, intact. Which means that
the result of the encoding is readable and the encoding can be applied almost
unconditionally to all strings without hurting instantiation. Then this
encoding is applied wherever reference of a shared instance is used to form
e.g. name of buildout section or inside other codes. We apply this encoding
universally - in config files too to avoid breakage there - e.g. in enb.cfg to
protect from e.g. \n being inserted in the middle of comment resulting in YAML
breakage. See documentation of added xbuildout.py for details.
For 2 we switch from `json` to using `dumps` on an object and referring that
dumps result via `key` directive.
See the following links for preliminary discussions with Jérome and Vincent on
this topic:
kirr/slapos@d5d4f7c8
nexedi/slapos@bf6b2ef3
Showing