Open Stack

Alexey, Eugene

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.

On Mon, Dec 7, 2015 at 10:47 PM, Andrew Woodward <xarses at gmail.com> wrote:

> 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.
>
> On Mon, Dec 7, 2015 at 11:36 AM Oleg Gelbukh <ogelbukh at mirantis.com>
> wrote:
>
>> +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.
>>
>> 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.
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Mon, Dec 7, 2015 at 9:29 PM, Eugene Korekin <ekorekin at mirantis.com>
>> wrote:
>>
>>> Stas,
>>>
>>> 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?
>>>
>>>
>>>
>>> On 07.12.2015 20:38, Stanislaw Bogatkin wrote:
>>>
>>> +1 to Andrew. Plugins created for run some code and plugin verification
>>> is the source of trust there.
>>>
>>> On Mon, Dec 7, 2015 at 8:19 PM, Andrew Woodward <xarses at gmail.com>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>> On Mon, Dec 7, 2015 at 9:14 AM Eugene Korekin <ekorekin at mirantis.com>
>>>> wrote:
>>>>
>>>>> As far as I know this feature is planned for the next releases.
>>>>>
>>>>> 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.
>>>>>
>>>>> Unfortunately, by installing some plugin a user jeopardizes his
>>>>> existing environments. And I think we should at least document these risks.
>>>>>
>>>>>
>>>>> On 07.12.2015 19:52, Javeria Khan wrote:
>>>>>
>>>>> My two cents. It would be useful to have a role that could execute on
>>>>> the Fuel Master host itself rather than a container.
>>>>>
>>>>> --
>>>>> Javeria
>>>>> On Dec 7, 2015 9:49 PM, "Roman Prykhodchenko" < <me at romcheg.me>
>>>>> me at romcheg.me> wrote:
>>>>>
>>>>>> Alexey,
>>>>>>
>>>>>> thank you for bringing this up. IMO discussing security problems is
>>>>>> better to be done in a special kind of Launchpad bugs.
>>>>>>
>>>>>> - romcheg
>>>>>>
>>>>>>
>>>>>> > 7 груд. 2015 р. о 17:36 Alexey Elagin <aelagin at mirantis.com>
>>>>>> написав(ла):
>>>>>> >
>>>>>> > Hello all,
>>>>>> >
>>>>>> > We have a security problem in Fuel 7.0. It's related to plugin
>>>>>> > development and allows to execute code in mcollective docker
>>>>>> container
>>>>>> > on Fuel master node. Any fuel plugin may contains a yaml file with
>>>>>> > deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and there
>>>>>> is
>>>>>> > an ability to run some code on node with role "master". It's also
>>>>>> > possible to connect to any target node via ssh without a password
>>>>>> from
>>>>>> > within the container.
>>>>>> >
>>>>>> > As i understood, it was made to simplify some deployment cases. I
>>>>>> see
>>>>>> > some steps for resolving this situation:
>>>>>> > 1. Fuel team should disallow
>>>>>> > execution of any puppet manifests or bash code on nodes with master
>>>>>> > role.
>>>>>> > 2. Append the Fuel documentation. Notify users about this
>>>>>> > security issue.
>>>>>> >
>>>>>> > What do you think about it? What deployment cases which require
>>>>>> > execution of code on role "master" do you know?
>>>>>> >
>>>>>> > --
>>>>>> > Best regards,
>>>>>> > Alexey
>>>>>> > Deployment Engineer
>>>>>> > Mirantis, Inc
>>>>>> > Cell: +7 (968) 880 2288 <%2B7%20%28968%29%20880%202288>
>>>>>> > Skype: shikelbober
>>>>>> > Slack: aelagin
>>>>>> > mailto:aelagin at mirantis.com
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> __________________________________________________________________________
>>>>>> > OpenStack Development Mailing List (not for usage questions)
>>>>>> > Unsubscribe:
>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> __________________________________________________________________________
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>> --
>>>>> Eugene Korekin
>>>>> Partner Enablement Team Deployment Engineer
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>> --
>>>>
>>>> --
>>>>
>>>> Andrew Woodward
>>>>
>>>> Mirantis
>>>>
>>>> Fuel Community Ambassador
>>>>
>>>> Ceph Community
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> --
>>> Eugene Korekin
>>> Partner Enablement Team Deployment Engineer
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151207/ee9ab71d/attachment.html>