[
https://issues.apache.org/jira/browse/MESOS-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171462#comment-15171462
]
Marco Massenzio commented on MESOS-4253:
----------------------------------------
It would be good if whoever came up with the "security concerns" could clarify
them further: in particular, when making an assertion about a particular
feature introducing a "security vulnerability", it is best practice to describe
a scenario, a potential attacker's capabilities, and the attack vector -
otherwise, *anything* can be a "security concern."
{quote}
What this means is that I have to retract the ship-it to discuss it further.
One of the most important issues was the fact that exposing all Master/Agent
flags could also mean sharing things like credentials and password info and any
other information that is part of other modules' module.json parameters.
{quote}
I will be honest and confess that I don't understand the scenario here: please
bear in mind that the module(s) can *only* be loaded at startup, by using the
{{--modules}} flag (and associated JSON) by the same person/team/script that is
launching the Master/Agent.
So, we are really *not* "exposing" the flags: these are already available (by
definition) to the actor who launched the Agent (or Master), hence this
facility does not further expand the surface of attack (provided, of course,
that the module itself is designed according to security principles).
In other words, passing the Flags during module creation is simply a
convenience, wrt to writing a "wrapper" script that duplicates these Flags of
interest into the modules' "Parameters" in the JSON.
Also, it gives the modules access to default values that are not explicitly
defined: as these are, by definition, "public" there is no increase in
vulnerability.
Again, the very same person that launches Mesos is loading the module - how
does that represent a greater security concern?
{quote}
Having said that, I am not saying that Mesos is completely secure and these
patches will make it less secure, but we do need to comeup with a better plan
going forward.
{quote}
"better" can only be defined wrt to a security threat scenario: what is it?
{quote}
On a more detailed note, there are two main avenues that we need to pursue
here. One, have the modules explicitly request the flags that are needed by
them in order to work. At which point, the operator can pass in these flags as
part of Master/Agent commandline and they will be forwarded to the respective
modules.
{quote}
how would a module "explicitly request the flags"?
This seems rather cumbersome, and only minimally better than just the
"wrapper" script that duplicates the flags inside the JSON's parameters.
It is also completely contrary to treating your cluster "as herd, not pets."
{quote}
Second, we can come up with a minimal set of Master/Agent flags that we
consider "safe" and always pass to all modules as part of the `create` call
along with Parameters. There is already a precedence in the way SSL flags are
passed on via Master/Agent commandline.
{quote}
This seems to me to be really non-scalable and a bit cumbersome, but probably
the only viable option, without a clearer definition of what the security
concerns are.
{quote}
Finally, given the nature of the concerns, I wanted to see if you can join the
next community sync and discuss it further while involving the whole community?
After that, we might be able to create a small working group with all
interested parties to come up with better design decisions.
{quote}
Considering that it's taken two months (of virtually no feedback at all) I
honestly can't see how this is likely to elicit more interest, but we'll see, I
guess.
> Provide a minimalist "runtime context" to an Anonymous Module
> -------------------------------------------------------------
>
> Key: MESOS-4253
> URL: https://issues.apache.org/jira/browse/MESOS-4253
> Project: Mesos
> Issue Type: Improvement
> Components: modules
> Reporter: Marco Massenzio
> Assignee: Marco Massenzio
>
> Currently, {{Anonymous}} modules only receive at creation a copy of the
> {{"parameters"}} passed in the JSON configuration file.
> However, at runtime, it would be useful to also have a "runtime context" for
> the module developer to use, when implementing the functionality.
> I would suggest to pass in the {{Flags}} object from the Master/Agent inside
> an {{setRuntimeContext(const Flags&)}}[0] method, called immediately
> post-{{create(const Parameters&)}}[1].
> Also, I would suggest adding a {{teardown()}} method too, in case the module
> needs to release resources / conduct cleanup before exiting (there is a TODO
> in the code to this effect, and adding this in this patch would be close to
> trivial).
> [0] In practice, it won't be this trivial, as Master/Agent {{Flags}} are of a
> different compile-time type - probably use something like variadic templates
> or something (suggestions appreciated!).
> [1] In fact, the ideal solution would be to add the {{const Flags&}} to
> {{create()}}, but that would, alas, break everyone's modules; so that's
> probably a no-go (ideas welcome here too).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
