[jira] [Commented] (MESOS-6953) A compromised mesos-master node can execute code as root on agents.
[
https://issues.apache.org/jira/browse/MESOS-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855046#comment-15855046
]
Anindya Sinha commented on MESOS-6953:
--
For the immediate issue at hand, the proposal is to configure {{acls}} to add a
new acl type for the agent (currently, this acl type is only supported on the
master), viz. {{run_tasks}} to denote users allowed to run tasks on the agent.
Note that as far as deployment goes, the {{run_tasks}} acl should be present in
every agent in the cluster and should match with the {{run_tasks}} acl
configured on the master.
In {{acls}}, a global flag {{permissive}} defines the following:
It defines the behavior when no ACL applies to the request made. If set to true
(which is the default) it will allow by default all non-matching requests, if
set to false it will reject all non-matching requests.
If no {{run_tasks}} acl is specified when {{permissive}} is {{true}} (default),
all users shall be allowed to launch tasks. However, if {{permissive}} is
{{false}} and no {{run_tasks}} acl is configured, it would imply no user would
be able to launch tasks which is due to the very definition of the global
{{permissive}} flag, and operators would need to configure the {{run_tasks}}
acl before upgrading (if {{permissive}} is {{false}}).
One way to enhance this condition to have the notion of {{permissive}} for each
acl type (instead of a global {{permissive}}). Opened
https://issues.apache.org/jira/browse/MESOS-7066 for that issue.
> A compromised mesos-master node can execute code as root on agents.
> ---
>
> Key: MESOS-6953
> URL: https://issues.apache.org/jira/browse/MESOS-6953
> Project: Mesos
> Issue Type: Bug
> Components: security
>Reporter: Anindya Sinha
>Assignee: Anindya Sinha
> Labels: security, slave
>
> mesos-master has a `--[no-]root_submissions` flag that controls whether
> frameworks with `root` user are admitted to the cluster.
> However, if a mesos-master node is compromised, it can attempt to schedule
> tasks on agent as the `root` user. Since mesos-agent has no check against
> tasks running on the agent for specific users, tasks can get run with `root`
> privileges can get run within the container on the agent.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MESOS-6953) A compromised mesos-master node can execute code as root on agents.
[
https://issues.apache.org/jira/browse/MESOS-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15840529#comment-15840529
]
Anindya Sinha commented on MESOS-6953:
--
The main motivation here is not allow agents to run tasks with {{root}}
privileges and do bad things on the agent. However, I agree we can extend this
to other operations such as {{TEARDOWN_FRAMEWORK}}, and maybe to
{{CREATE_VOLUME}} and {{DESTROY_VOLUME}} as well in addition to launching of
tasks.
If we decide to do a long term solution, that can be tracked separately. This
ticket captures what we can do right now to protect from the said scenario.
> A compromised mesos-master node can execute code as root on agents.
> ---
>
> Key: MESOS-6953
> URL: https://issues.apache.org/jira/browse/MESOS-6953
> Project: Mesos
> Issue Type: Bug
> Components: security
>Reporter: Anindya Sinha
>Assignee: Anindya Sinha
> Labels: security, slave
>
> mesos-master has a `--[no-]root_submissions` flag that controls whether
> frameworks with `root` user are admitted to the cluster.
> However, if a mesos-master node is compromised, it can attempt to schedule
> tasks on agent as the `root` user. Since mesos-agent has no check against
> tasks running on the agent for specific users, tasks can get run with `root`
> privileges can get run within the container on the agent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6953) A compromised mesos-master node can execute code as root on agents.
[ https://issues.apache.org/jira/browse/MESOS-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15838700#comment-15838700 ] Vinod Kone commented on MESOS-6953: --- Is this a short term solution? Why are you only protecting against the "run task" message from master? What about other messages like "kill task", "shutdown framework" etc that can come from a compromised master? The right long term solution sounds like mutual authentication/authorization between master and agent. > A compromised mesos-master node can execute code as root on agents. > --- > > Key: MESOS-6953 > URL: https://issues.apache.org/jira/browse/MESOS-6953 > Project: Mesos > Issue Type: Bug > Components: security >Reporter: Anindya Sinha >Assignee: Anindya Sinha > Labels: security, slave > > mesos-master has a `--[no-]root_submissions` flag that controls whether > frameworks with `root` user are admitted to the cluster. > However, if a mesos-master node is compromised, it can attempt to schedule > tasks on agent as the `root` user. Since mesos-agent has no check against > tasks running on the agent for specific users, tasks can get run with `root` > privileges can get run within the container on the agent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6953) A compromised mesos-master node can execute code as root on agents.
[
https://issues.apache.org/jira/browse/MESOS-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15837018#comment-15837018
]
Anindya Sinha commented on MESOS-6953:
--
In a normal case (when master is not compromised), we should always have the
same acls for {{run_tasks}} on each agent of the cluster, so the framework
should be sure that the tasks would launch on any agent if it passes
authorization on the master. In the case of a compromised master, we do not
want the agent to launch tasks as a privileged user. The check against the
{{run_tasks}} acl on the agent is just for that purpose.
Regarding the live upgrade case: If this functionality is desired (i.e. to
protect against running tasks on the agent as privileged users through a
compromised master), we need to add the {{run_tasks}} acl (not all acls) on
each agent that matches with the {{run_tasks}} acl on the master.
Another option instead of using framework principal as the "subject" could be
to add another flag for mesos-slave that enlists the {{whitelisted_users}}
(instead of using {{acls}}) which the agent checks to ensure that the task user
for the task that is going to be launched is included in that list of
whitelisted users. The reason of using {{acls}} on the agent is mainly to reuse
existing authorization module.
> A compromised mesos-master node can execute code as root on agents.
> ---
>
> Key: MESOS-6953
> URL: https://issues.apache.org/jira/browse/MESOS-6953
> Project: Mesos
> Issue Type: Bug
> Components: security
>Reporter: Anindya Sinha
>Assignee: Anindya Sinha
> Labels: security, slave
>
> mesos-master has a `--[no-]root_submissions` flag that controls whether
> frameworks with `root` user are admitted to the cluster.
> However, if a mesos-master node is compromised, it can attempt to schedule
> tasks on agent as the `root` user. Since mesos-agent has no check against
> tasks running on the agent for specific users, tasks can get run with `root`
> privileges can get run within the container on the agent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6953) A compromised mesos-master node can execute code as root on agents.
[ https://issues.apache.org/jira/browse/MESOS-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15836937#comment-15836937 ] Adam B commented on MESOS-6953: --- cc: [~arojas] Interesting.. So you use the framework principal as the "subject", although it's the master that's actually making the request? So, now, if a framework wants to run a task, it must have permission not just on the masters, but also on every agent (where it might want to run)? What if it has the ACL on some agents, but not others? How would it discover that, by trial and error? What's the live upgrade story here? Operators must copy the run_tasks ACL from the masters to all agents (and restart the agents)? > A compromised mesos-master node can execute code as root on agents. > --- > > Key: MESOS-6953 > URL: https://issues.apache.org/jira/browse/MESOS-6953 > Project: Mesos > Issue Type: Bug > Components: security >Reporter: Anindya Sinha >Assignee: Anindya Sinha > Labels: security, slave > > mesos-master has a `--[no-]root_submissions` flag that controls whether > frameworks with `root` user are admitted to the cluster. > However, if a mesos-master node is compromised, it can attempt to schedule > tasks on agent as the `root` user. Since mesos-agent has no check against > tasks running on the agent for specific users, tasks can get run with `root` > privileges can get run within the container on the agent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
