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

[Eugene Korekin]

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 our current state of things it's quite possible that there 
would be some side effects affecting other environments, not only the 
one for which we want to enable the aforementioned plugin.
3) I perfectly understand that current Fuel architecture does not allow 
for some strict separation of access to various environments if the user 
has access to Fuel master node. I think this is the root of the issue.



On 07.12.2015 23:43, Vladimir Kuklin wrote:

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. Simple downloading of a 3rd party file from the internet 
imposes the same restrictions. We could obviously introduce more 
features for security audit of the plugins, but  I would not set 
priority of this particular issue as high as it is actually what can 
be confined by the user himself by applying precautious actions. So, 
it seems, that benefits of introducing additional measures of security 
hardening of plugins may be outweighed by their drawbacks.


On Mon, Dec 7, 2015 at 10:47 PM, Andrew Woodward > wrote:


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, deploying, maintaining and erasing
nodes. Everything we do,  want to do, and want other to do is
'dangerous' we need to limit a users risk with verification of
plugins not creating rules that limit functions plugins have
access to.

On Mon, Dec 7, 2015 at 11:36 AM Oleg Gelbukh
> wrote:

+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 flexibility of
deployment. That could be achieved by turning the 'core'
components into pluggable options, and reducing the 'core'  to
the set of replaceable plugins shipped with the reference
architecture. This will eliminate the need for many of the
hack used nowadays in plugins to override default behaviours.

--
Best regards,
Oleg Gelbukh

On Mon, Dec 7, 2015 at 9:29 PM, Eugene Korekin
> wrote:

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

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

[Roman Prykhodchenko]

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 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:aela...@mirantis.com
> 
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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

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

[Alexey Elagin]

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:aela...@mirantis.com


__
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

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

[Stanislaw Bogatkin]

+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 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 
> 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"  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> написав(ла):
>>> >
>>> > 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:aela...@mirantis.com
>>> >
>>> >
>>> >
>>> __
>>> > 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
>>>
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@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-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://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

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

[Andrew Woodward]

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  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"  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 
>> написав(ла):
>> >
>> > 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:aela...@mirantis.com
>> >
>> >
>> >
>> __
>> > 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
>>
>>
>> __
>> 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
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@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-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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Javeria Khan]

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
> 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 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:aela...@mirantis.com
> >
> >
> >
> __
> > 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
>
>
> __
> 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
>
>
__
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

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

[Eugene Korekin]

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" > 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 > написав(ла):
>
> 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:aela...@mirantis.com 
>
>
>
__
> 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


__
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



__
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

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

[Eugene Korekin]

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 > 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" > 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 > написав(ла):
>
> 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:aela...@mirantis.com 
>
>
>

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



__
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



__
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

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

[Oleg Gelbukh]

+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 flexibility of deployment.
That could be achieved by turning the 'core' components into pluggable
options, and reducing the 'core'  to the set of replaceable plugins shipped
with the reference architecture. This will eliminate the need for many of
the hack used nowadays in plugins to override default behaviours.

--
Best regards,
Oleg Gelbukh

On Mon, Dec 7, 2015 at 9:29 PM, Eugene Korekin 
wrote:

> 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  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 
>> 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> 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 
 написав(ла):
 >
 > 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 <%2B7%20%28968%29%20880%202288>
 > Skype: shikelbober
 > Slack: aelagin
 > mailto:aela...@mirantis.com
 >
 >
 >
 __
 > 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



 __
 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


>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> 

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

[Andrew Woodward]

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,
deploying, maintaining and erasing nodes. Everything we do,  want to do,
and want other to do is 'dangerous' we need to limit a users risk with
verification of plugins not creating rules that limit functions plugins
have access to.

On Mon, Dec 7, 2015 at 11:36 AM Oleg Gelbukh  wrote:

> +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 flexibility of deployment.
> That could be achieved by turning the 'core' components into pluggable
> options, and reducing the 'core'  to the set of replaceable plugins shipped
> with the reference architecture. This will eliminate the need for many of
> the hack used nowadays in plugins to override default behaviours.
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Mon, Dec 7, 2015 at 9:29 PM, Eugene Korekin 
> wrote:
>
>> 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  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 
>>> 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> 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 
> написав(ла):
> >
> > 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 <%2B7%20%28968%29%20880%202288>
> > Skype: shikelbober
> > Slack: aelagin
> > mailto:aela...@mirantis.com
> >
> >
> >
> __
> > OpenStack Development Mailing List 

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

[Vladimir Kuklin]

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. Simple
downloading of a 3rd party file from the internet imposes the same
restrictions. We could obviously introduce more features for security audit
of the plugins, but  I would not set priority of this particular issue as
high as it is actually what can be confined by the user himself by applying
precautious actions. So, it seems, that benefits of introducing additional
measures of security hardening of plugins may be outweighed by their
drawbacks.

On Mon, Dec 7, 2015 at 10:47 PM, Andrew Woodward  wrote:

> 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,
> deploying, maintaining and erasing nodes. Everything we do,  want to do,
> and want other to do is 'dangerous' we need to limit a users risk with
> verification of plugins not creating rules that limit functions plugins
> have access to.
>
> On Mon, Dec 7, 2015 at 11:36 AM Oleg Gelbukh 
> wrote:
>
>> +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 flexibility of deployment.
>> That could be achieved by turning the 'core' components into pluggable
>> options, and reducing the 'core'  to the set of replaceable plugins shipped
>> with the reference architecture. This will eliminate the need for many of
>> the hack used nowadays in plugins to override default behaviours.
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Mon, Dec 7, 2015 at 9:29 PM, Eugene Korekin 
>> wrote:
>>
>>> 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 
>>> 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 
 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> 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 
>> написав(ла):
>> >
>> > 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 

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

[Adam Heczko]

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 plugin certification here.
Not sure if certified plugins are signed actually / and if there is any
possibility to check signatures prior to (or during) plugin installation?

A.

On Mon, Dec 7, 2015 at 7:29 PM, Eugene Korekin 
wrote:

> 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  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 
>> 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> 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 
 написав(ла):
 >
 > 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 <%2B7%20%28968%29%20880%202288>
 > Skype: shikelbober
 > Slack: aelagin
 > mailto:aela...@mirantis.com
 >
 >
 >
 __
 > 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



 __
 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


>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> --
>>> Eugene Korekin
>>> Partner Enablement Team Deployment Engineer
>>>
>>>
>>> 

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

[Eugene Korekin]

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 > 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
> 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" > 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
>
написав(ла):
>
> 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:aela...@mirantis.com 
>
>
>

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



__
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




__
OpenStack Development Mailing List (not