<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 class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 7, 2015 at 9:29 PM, Eugene Korekin <span dir="ltr"><<a href="mailto:ekorekin@mirantis.com" target="_blank">ekorekin@mirantis.com</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 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">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 href="mailto:ekorekin@mirantis.com" target="_blank">ekorekin@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 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 href="mailto:me@romcheg.me" target="_blank"></a><a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</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 href="mailto:aelagin@mirantis.com" target="_blank">aelagin@mirantis.com</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 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 href="mailto:aelagin@mirantis.com" target="_blank">aelagin@mirantis.com</a><br>
><br>
><br>
>
__________________________________________________________________________<br>
> OpenStack Development Mailing List (not
for usage questions)<br>
> Unsubscribe: <a 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 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>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for
usage questions)<br>
Unsubscribe: <a 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 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>
<fieldset></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a 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 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 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>
</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 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 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 href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a 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 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 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>