Open Stack

Yes, I am aware that this is the expected behavior, at least from the 
developer point of view.

Still, some functionality to confine plugin actions within the 
environment where it is supposed to run would be an useful option, what 
do you think?


On 07.12.2015 20:19, Andrew Woodward 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 
> <mailto: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
>>     <mailto: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
>>         <mailto: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 <tel:%2B7%20%28968%29%20880%202288>
>>         > Skype: shikelbober
>>         > Slack: aelagin
>>         > mailto:aelagin at mirantis.com <mailto:aelagin at mirantis.com>
>>         >
>>         >
>>         >
>>         __________________________________________________________________________
>>         > OpenStack Development Mailing List (not for usage questions)
>>         > Unsubscribe:
>>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>         <http://OpenStack-dev-request@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://OpenStack-dev-request@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
>>     <mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
>>     http://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://OpenStack-dev-request@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

-- 
Eugene Korekin
Partner Enablement Team Deployment Engineer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151207/49f4058f/attachment.html>