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
Please register or sign in to comment