Open Stack

+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> 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>
>>> 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
>>> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151207/51073a31/attachment.html>