<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><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 7, 2015 at 11:36 AM Oleg Gelbukh <<a href="mailto:ogelbukh@mirantis.com">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 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>
__________________________________________________________________________<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 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>