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 <xar...@gmail.com
<mailto:xar...@gmail.com>> 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
<ogelb...@mirantis.com <mailto:ogelb...@mirantis.com>> 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
<ekore...@mirantis.com <mailto:ekore...@mirantis.com>> 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
<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
<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
__________________________________________________________________________
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
--
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru <http://www.mirantis.ru/>
vkuk...@mirantis.com <mailto:vkuk...@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
--
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
