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 <xar...@gmail.com
<mailto:xar...@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
<ekore...@mirantis.com <mailto:ekore...@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" <m...@romcheg.me
<mailto:m...@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
<aela...@mirantis.com <mailto:aela...@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:aela...@mirantis.com <mailto:aela...@mirantis.com>
>
>
>
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage
questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
