+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 <[email protected]> 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 <[email protected]> > 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" <[email protected]> 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 < <[email protected]> >>> [email protected]> написав(ла): >>> > >>> > 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:[email protected] >>> > >>> > >>> > >>> __________________________________________________________________________ >>> > OpenStack Development Mailing List (not for usage questions) >>> > Unsubscribe: >>> [email protected]?subject:unsubscribe >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?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: >> [email protected]?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
