<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Vladimir,<br>
<br>
I want to emphasize that my main concern is not with arbitrary code
execution on master node. I have no problem with that if there is
only one OpenStack environment.<br>
<br>
What I am concerned about is this:<br>
<br>
1) In general case user installs plugin for the one environment
only.<br>
2) But in our current state of things it's quite possible that there
would be some side effects affecting other environments, not only
the one for which we want to enable the aforementioned plugin.<br>
3) I perfectly understand that current Fuel architecture does not
allow for some strict separation of access to various environments
if the user has access to Fuel master node. I think this is the root
of the issue.<br>
<br>
<br>
<div class="moz-cite-prefix">On 07.12.2015 23:43, Vladimir Kuklin
wrote:<br>
</div>
<blockquote
cite="mid:CAHAWLf0ENAu=UAY20SXzZGtM=Df+i7NPveGHeS-4zVoMbMMkKw@mail.gmail.com"
type="cite">
<div dir="ltr">Alexey, Eugene
<div><br>
</div>
<div>I understand your concerns, but it is what the plugin is
about - we allow to run tasks on the master node for the sake
of deployment flexibility. If you are concerned about security
complications you should either use certified plugins or even
test them by yourselves in a sandbox. Simple downloading of a
3rd party file from the internet imposes the same
restrictions. We could obviously introduce more features for
security audit of the plugins, but I would not set priority
of this particular issue as high as it is actually what can be
confined by the user himself by applying precautious actions.
So, it seems, that benefits of introducing additional measures
of security hardening of plugins may be outweighed by their
drawbacks. </div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Dec 7, 2015 at 10:47 PM, Andrew
Woodward <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Guys, we can not create any limitations on
plugins ability to do things that we allow with the 'core'
system. We need to be lees strict and more flexible with
the plugin framework not constrict it randomly because
there is a way to execute dangerous code. We are in the
business of buiding, deploying, maintaining and erasing
nodes. Everything we do, want to do, and want other to do
is 'dangerous' we need to limit a users risk with
verification of plugins not creating rules that limit
functions plugins have access to.</div>
<div class="HOEnZb">
<div class="h5"><br>
<div class="gmail_quote">
<div dir="ltr">On Mon, Dec 7, 2015 at 11:36 AM Oleg
Gelbukh <<a moz-do-not-send="true"
href="mailto:ogelbukh@mirantis.com"
target="_blank">ogelbukh@mirantis.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">+1 to Eugene here. Eventually we will
need to more strictly define Plugins framework and
SDK and limit possible actions to the set of
supported ones. This is required not only for
security and/or stability reasons, but for upgrade
purposes as well.
<div><br>
</div>
<div>On the other hand, we need to retain certain
flexibility of deployment. That could be
achieved by turning the 'core' components into
pluggable options, and reducing the 'core' to
the set of replaceable plugins shipped with the
reference architecture. This will eliminate the
need for many of the hack used nowadays in
plugins to override default behaviours.<br>
<div><br>
</div>
<div>--</div>
<div>Best regards,</div>
<div>Oleg Gelbukh</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Dec 7, 2015 at
9:29 PM, Eugene Korekin <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ekorekin@mirantis.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ekorekin@mirantis.com">ekorekin@mirantis.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Stas,<br>
<br>
I fear that often even developer of a code
cannot verify his own code completely, let
alone some third-party validation teams.
Does the ability to strictly limit plugin
actions by the list of intended
environments looks nonviable to you?
<div>
<div><br>
<br>
<br>
<div>On 07.12.2015 20:38, Stanislaw
Bogatkin wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">+1 to Andrew. Plugins
created for run some code and
plugin verification is the source
of trust there.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon,
Dec 7, 2015 at 8:19 PM, Andrew
Woodward <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:xarses@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:xarses@gmail.com">xarses@gmail.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">I'd have to say
that this is expected
behavior. I'm not sure what
you would hope to prohibit
when these kinds of things
are necessary for the
deployment. We also can't
prohibit this from being
done in a plugin, this is
what the plugin verification
is supposed to help combat.
If you just go download a
random puppet manifest //
script // etc... from the
internet, how do you ensure
that it didn't install a
root-kit.</div>
<div>
<div><br>
<div class="gmail_quote">
<div dir="ltr">On Mon,
Dec 7, 2015 at 9:14 AM
Eugene Korekin <<a
moz-do-not-send="true" href="mailto:ekorekin@mirantis.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ekorekin@mirantis.com">ekorekin@mirantis.com</a></a>>
wrote:<br>
</div>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF"
text="#000000"> As
far as I know this
feature is planned
for the next
releases.<br>
<br>
But I think the main
problem is: it's not
obvious that just by
installing a plugin,
even without
enabling the plugin
in Fuel user could
break or somehow
alter already
existing
environments. It
could be done by
malicious attacker
who could compromise
plugin or just
unintentionally with
some bug in the
plugin code. <br>
<br>
Unfortunately, by
installing some
plugin a user
jeopardizes his
existing
environments. And I
think we should at
least document these
risks.</div>
<div bgcolor="#FFFFFF"
text="#000000"><br>
<br>
<div>On 07.12.2015
19:52, Javeria
Khan wrote:<br>
</div>
<blockquote
type="cite">
<p dir="ltr">My
two cents. It
would be useful
to have a role
that could
execute on the
Fuel Master host
itself rather
than a
container.</p>
<p dir="ltr">--<br>
Javeria</p>
<div
class="gmail_quote">On
Dec 7, 2015 9:49
PM, "Roman
Prykhodchenko"
<<a
moz-do-not-send="true"
href="mailto:me@romcheg.me" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:me@romcheg.me">me@romcheg.me</a></a>> wrote:<br
type="attribution">
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">Alexey,<br>
<br>
thank you for
bringing this
up. IMO
discussing
security
problems is
better to be
done in a
special kind
of Launchpad
bugs.<br>
<br>
- romcheg<br>
<br>
<br>
> 7 груд.
2015 р. о
17:36 Alexey
Elagin <<a
moz-do-not-send="true" href="mailto:aelagin@mirantis.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:aelagin@mirantis.com">aelagin@mirantis.com</a></a>>
написав(ла):<br>
><br>
> Hello
all,<br>
><br>
> We have a
security
problem in
Fuel 7.0. It's
related to
plugin<br>
>
development
and allows to
execute code
in mcollective
docker
container<br>
> on Fuel
master node.
Any fuel
plugin may
contains a
yaml file with<br>
>
deployment
tasks
(tasks.yaml,
deployment_tasks.yaml
etc) and there
is<br>
> an
ability to run
some code on
node with role
"master". It's
also<br>
> possible
to connect to
any target
node via ssh
without a
password from<br>
> within
the container.<br>
><br>
> As i
understood, it
was made to
simplify some
deployment
cases. I see<br>
> some
steps for
resolving this
situation:<br>
> 1. Fuel
team should
disallow<br>
> execution
of any puppet
manifests or
bash code on
nodes with
master<br>
> role.<br>
> 2. Append
the Fuel
documentation.
Notify users
about this<br>
> security
issue.<br>
><br>
> What do
you think
about it? What
deployment
cases which
require<br>
> execution
of code on
role "master"
do you know?<br>
><br>
> --<br>
> Best
regards,<br>
> Alexey<br>
>
Deployment
Engineer<br>
> Mirantis,
Inc<br>
> Cell: <a
moz-do-not-send="true" href="tel:%2B7%20%28968%29%20880%202288"
value="+79688802288"
target="_blank">+7 (968) 880 2288</a><br>
> Skype:
shikelbober<br>
> Slack:
aelagin<br>
> mailto:<a
moz-do-not-send="true" href="mailto:aelagin@mirantis.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:aelagin@mirantis.com">aelagin@mirantis.com</a></a><br>
><br>
><br>
>
__________________________________________________________________________<br>
> OpenStack
Development
Mailing List
(not for usage
questions)<br>
>
Unsubscribe: <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></a><br>
> <a
moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank"><a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack
Development
Mailing List
(not for usage
questions)<br>
Unsubscribe: <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></a><br>
<a
moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank"><a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></a><br>
<br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a moz-do-not-send="true" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a moz-do-not-send="true" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div>
<div bgcolor="#FFFFFF"
text="#000000">
<pre cols="72">--
Eugene Korekin
Partner Enablement Team Deployment Engineer</pre>
</div>
__________________________________________________________________________<br>
OpenStack Development
Mailing List (not for
usage questions)<br>
Unsubscribe: <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></a><br>
<a
moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer"
target="_blank"><a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></a><br>
</blockquote>
</div>
<div dir="ltr">-- <br>
</div>
</div>
</div>
<div dir="ltr">
<p dir="ltr">--</p>
<p dir="ltr"><span
style="font-size:13.1999998092651px">Andrew
Woodward</span></p>
<p dir="ltr"><span
style="font-size:13.1999998092651px">Mirantis</span></p>
<p dir="ltr"><span
style="font-size:13.1999998092651px">Fuel
Community Ambassador</span></p>
<p dir="ltr"><span
style="font-size:13.1999998092651px">Ceph
Community</span></p>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing
List (not for usage questions)<br>
Unsubscribe: <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a moz-do-not-send="true" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a moz-do-not-send="true" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<pre cols="72">--
Eugene Korekin
Partner Enablement Team Deployment Engineer</pre>
</div>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for
usage questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<div dir="ltr">-- <br>
</div>
<div dir="ltr">
<p dir="ltr">--</p>
<p dir="ltr"><span
style="font-size:13.1999998092651px">Andrew
Woodward</span></p>
<p dir="ltr"><span
style="font-size:13.1999998092651px">Mirantis</span></p>
<p dir="ltr"><span
style="font-size:13.1999998092651px">Fuel
Community Ambassador</span></p>
<p dir="ltr"><span
style="font-size:13.1999998092651px">Ceph
Community</span></p>
</div>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">Yours Faithfully,<br>
Vladimir Kuklin,<br>
Fuel Library Tech Lead,<br>
Mirantis, Inc.<br>
+7 (495) 640-49-04<br>
+7 (926) 702-39-68<br>
Skype kuklinvv<br>
35bk3, Vorontsovskaya Str.<br>
Moscow, Russia,<br>
<a moz-do-not-send="true" href="http://www.mirantis.ru/"
target="_blank">www.mirantis.com</a><br>
<a moz-do-not-send="true" href="http://www.mirantis.ru/"
target="_blank">www.mirantis.ru</a><br>
<a moz-do-not-send="true"
href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Eugene Korekin
Partner Enablement Team Deployment Engineer</pre>
</body>
</html>