mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marco Massenzio" <ma...@mesosphere.io>
Subject Re: Review Request 36389: Enable remote execution of arbitrary command.
Date Wed, 15 Jul 2015 19:42:44 GMT


> On July 15, 2015, 6:13 p.m., Artem Harutyunyan wrote:
> > To make sure that this is fool proof(ish), I would suggest that this should only
ship only when the Authorizer framework (mentioned in the TODO comment) becomes available.
Also, I would add a screaming comment to --usage, something along the lines of 'this is insecure,
and this enables arbitrary command executrion with root privileges'. 
> > 
> > In general, I am of the firm opinion that this feature should come with a whitelisting
mechanism that will allow operators to whitelist (benign) commands that they want to execute,
and forbid anything else.

>To make sure that this is fool proof(ish), I would suggest that this should only ship
only when the Authorizer framework (mentioned in the TODO comment) becomes available. Also,
I would add a screaming comment to --usage, something along the lines of 'this is insecure,
and this enables arbitrary command executrion with root privileges'. 

This has to be deliberately enabled:
```
--allow_remote_execution

      Allows the execution of arbitrary shell commands on the Slave, by
      POSTing to the /execute endpoint with a JSON-serialized CommandInfo
      protobuf, containing the command to execute and, optionally, the
      arguments.
      WARNING: this may cause a security vulnerability and is disabled by
      default; enable only if you know exactly what you are doing.
```

The WARNING seems explicit enough to me, but if people agree, I'm happy TO MAKE IT SCREAM
;-)

> In general, I am of the firm opinion that this feature should come with a whitelisting
mechanism that will allow operators to whitelist (benign) commands that they want to execute,
and forbid anything else.

Perhaps; but please note that this is meant mostly for emergency/off-cycle maintenance reasons,
so it's very difficult to know in advance *what* you will need (if you did, you probably wouldn't
need the feauture in the first place).
This is also meant to be a "highly scriptable" endpoint, where you have either a generating
function or a discovery methodology, that finds out (potentially 1,000s of) IPs for your Slaves
and then does in very rapid succession a POST with the command to execute (I'm envisioning
some catastrophic failure mode that needs to be prevented; or a security breach; or something
like that).

In any event, in modern systems, the way to "protect" these endpoints is at the network security
level, by isolating services within a protected, private subnet, with access granted only
from "bastion" servers (hardened and secured) - re-implementing authentication/authorization
on every single service is not only prone to leaving some vulnerable to security breaches,
but it also becomes quickly unmanageable (as you know have disparate, and inconsistent, security
policies and authentication mechanism and no centralized way to manage and revoke access).

(well, when I say "modern"... that was 5-6 years ago at Google... but I figure we were 4-5
years ahead of everyone else :) )


- Marco


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36389/#review91784
-----------------------------------------------------------


On July 14, 2015, 11:20 p.m., Marco Massenzio wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/36389/
> -----------------------------------------------------------
> 
> (Updated July 14, 2015, 11:20 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Cody Maloney.
> 
> 
> Bugs: MESOS-2830
>     https://issues.apache.org/jira/browse/MESOS-2830
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Jira: MESOS-2830
> 
> Under certain (maintenance) circumnstance, it may be necessary
> (or desirable) to execute arbitrary operator's commands on the
> slave (the entire fleet or a subset thereof) bypassing the Mesos
> Task execution mechanism; this may typically be necessary for
> maintenance and/or emergency actions.
> 
> This patch adds an HTTP endpoint (/execute) which accepts a
> JSON-encoded CommandInfo structure and executes the given
> command (with optional arguments).
> 
> The output of the command (along with potentially any stderr
> messages) is returned JSON-encoded in the Response.
> 
> For more details, see the design doc at:
> https://goo.gl/4npTMU
> 
> 
> Diffs
> -----
> 
>   src/slave/flags.hpp 26c778db2303167369af8675fe0441a00a1e9151 
>   src/slave/flags.cpp 8632677ebbdbfef8ffa45204b6f63a700baff7f3 
>   src/slave/main.cpp 8008430e98773d8be9ba5ac6385cffb2e351932a 
>   src/slave/slave.hpp dec4ca8323e151a6d0f9139214ff0ef6e3e3375a 
>   src/slave/slave.cpp 2119b5176aa7cfb7b0b551d4d4f65ee12818b9e4 
> 
> Diff: https://reviews.apache.org/r/36389/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> lots of manual testing (using Postman, REST client)
> 
> 
> Thanks,
> 
> Marco Massenzio
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message