• Kirill Smelkov's avatar
    software/ors-amarisoft: enb/generic: Protect from buildout code injection · c83fa3cb
    Kirill Smelkov authored
    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
    bf6b2ef3
    c83fa3cb
libinstance.jinja2.cfg 11.2 KB