Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

Vladimir, I want to emphasize that my main concern is not with arbitrary code execution on master node. I have no problem with that if there is only one OpenStack environment. What I am concerned about is this: 1) In general case user installs plugin for the one environment only. 2) But in

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

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 написав(ла): > > Hello all, > > We have a security problem in Fuel 7.0. It's related to

[openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

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

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

+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 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

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

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

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

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" wrote: > Alexey, > > thank you for bringing this up. IMO discussing security problems is better >

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

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

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

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:

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

+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

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

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,

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

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.

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

For future Fuel versions we could/should develop kind of RBAC model for accessing internal components. I'm not sure if current nailgun/astute provides any capability like this. Also plugins often interacts with operating system itself, which is another area of concern. IMO we could only rely on

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

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: