Logrotate container logger lets tasks execute arbitrary commands in the Mesos agent's namespace

The non-default LogrotateContainerLogger module allows tasks to configure sandbox log rotation (See http://mesos.apache.org/documentation/latest/logging/#Containers ). The logrotate_stdout_options and logrotate_stderr_options in particular let the task specify free-form text, which is written to a configuration file located in the task's sandbox. The module does not sanitize or check this configuration at all.

The logger itself will eventually run logrotate against the written configuration file, but the logger is not isolated in the same way as the task. For both the Mesos and Docker containerizers, the logger binary will run in the same namespace as the Mesos agent. This makes it possible to affect files outside of the task's mount namespace.

Two modes of attack are known to be problematic:

• Changing or adding entries to the configuration file. Normally, the configuration file contains a single file to rotate:

  /path/to/sandbox/stdout {
    <logrotate_stdout_options>
  }
  

  It is trivial to add text to the logrotate_stdout_options to add a new entry:

  /path/to/sandbox/stdout {
    <arbitrary options>
  }
  /path/to/other/file/on/disk {
    <arbitrary options>
  }
  

• Logrotate's postrotate option allows for execution of arbitrary commands. This can again be supplied with the logrotate_stdout_options variable.

  /path/to/sandbox/stdout {
    postrotate
      rm -rf /
    endscript
  }
  

Some potential fixes to consider:

• Overwrite the .logrotate.conf files each time. This would give only milliseconds between writing and calling logrotate for a thirdparty to modify the config files maliciously. This would not help if the task itself had postrotate options in its environment variables.
• Sanitize the free-form options field in the environment variables to remove postrotate or injection attempts like }\n/path/to/some/file\noptions{.
• Refactor parts of the Mesos isolation code path so that the logger and IO switchboard binary live in the same namespaces as the container (instead of the agent). This would also be nice in that the logger's CPU usage would then be accounted for within the container's resources.