[jira] [Assigned] (MESOS-9564) Logrotate container logger lets tasks execute arbitrary commands in the Mesos agent's namespace
[
https://issues.apache.org/jira/browse/MESOS-9564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Budnik reassigned MESOS-9564:
Assignee: Andrei Budnik (was: Joseph Wu)
> Logrotate container logger lets tasks execute arbitrary commands in the Mesos
> agent's namespace
> ---
>
> Key: MESOS-9564
> URL: https://issues.apache.org/jira/browse/MESOS-9564
> Project: Mesos
> Issue Type: Bug
> Components: agent, modules
>Reporter: Joseph Wu
>Assignee: Andrei Budnik
>Priority: Critical
> Labels: foundations, mesosphere
>
> 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:
> {code}
> /path/to/sandbox/stdout {
>
> }
> {code}
> It is trivial to add text to the {{logrotate_stdout_options}} to add a new
> entry:
> {code}
> /path/to/sandbox/stdout {
>
> }
> /path/to/other/file/on/disk {
>
> }
> {code}
> * Logrotate's {{postrotate}} option allows for execution of arbitrary
> commands. This can again be supplied with the {{logrotate_stdout_options}}
> variable.
> {code}
> /path/to/sandbox/stdout {
> postrotate
> rm -rf /
> endscript
> }
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MESOS-9564) Logrotate container logger lets tasks execute arbitrary commands in the Mesos agent's namespace
[
https://issues.apache.org/jira/browse/MESOS-9564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Mann reassigned MESOS-9564:
Shepherd: Greg Mann
Assignee: Joseph Wu
Sprint: Mesos Foundations RI11 Sp 40
Story Points: 5
> Logrotate container logger lets tasks execute arbitrary commands in the Mesos
> agent's namespace
> ---
>
> Key: MESOS-9564
> URL: https://issues.apache.org/jira/browse/MESOS-9564
> Project: Mesos
> Issue Type: Bug
> Components: agent, modules
>Reporter: Joseph Wu
>Assignee: Joseph Wu
>Priority: Critical
> Labels: foundations, mesosphere
>
> 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:
> {code}
> /path/to/sandbox/stdout {
>
> }
> {code}
> It is trivial to add text to the {{logrotate_stdout_options}} to add a new
> entry:
> {code}
> /path/to/sandbox/stdout {
>
> }
> /path/to/other/file/on/disk {
>
> }
> {code}
> * Logrotate's {{postrotate}} option allows for execution of arbitrary
> commands. This can again be supplied with the {{logrotate_stdout_options}}
> variable.
> {code}
> /path/to/sandbox/stdout {
> postrotate
> rm -rf /
> endscript
> }
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
