From robert.clark at hp.com  Tue Jul  2 10:28:07 2013
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 2 Jul 2013 10:28:07 +0000
Subject: [Openstack-security] Security Guide Now Available
Message-ID: <CDF869C4.16E8F%robert.clark@hp.com>

Hi All,

The OpenStack Security Guide is now available http://www.openstack.org/blog/2013/07/openstack-security-guide-now-available/

The guide was written last week in a book sprint with contributions from HP, Rackspace, Nebula, NSA, APL, Intel, CloudPassage, RedHat, CloudScaling,Nicira.

Special thanks should go to RedHat for funding much of the weeks expenses and to Adam who facilitated the booksprint. This document was a major undertaking and as a member of the OpenStack Security Group I'm proud to have this out there.

Cheers
-Rob




From 1195431 at bugs.launchpad.net  Tue Jul  2 13:12:30 2013
From: 1195431 at bugs.launchpad.net (OpenStack Hudson)
Date: Tue, 02 Jul 2013 13:12:30 -0000
Subject: [Openstack-security] [Bug 1195431] Re: kombu_ssl_version is a
	cfg.StrOpt but the ssl	socket code requires an Integer value
References: <20130627190934.25966.77326.malonedeb@soybean.canonical.com>
Message-ID: <20130702131230.19735.69755.malone@chaenomeles.canonical.com>

Fix proposed to branch: master
Review: https://review.openstack.org/35291

** Changed in: oslo
       Status: New => In Progress

** Changed in: oslo
     Assignee: (unassigned) => Davanum Srinivas (DIMS) (dims-v)

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1195431

Title:
  kombu_ssl_version is a cfg.StrOpt but the ssl socket code requires an
  Integer value

Status in Oslo - a Library of Common OpenStack Code:
  In Progress

Bug description:
  When specifying 'kombu_ssl_version' for the RPC driver such as either
  "kombu_ssl_version=3" or "kombu_ssl_version=SSLv3" the relevant
  OpenStack service (nova, cinder, etc) will fail with the following
  traceback:

  2013-06-27 15:05:30.257 CRITICAL cinder [-] an integer is required
  2013-06-27 15:05:30.257 TRACE cinder Traceback (most recent call last):
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/bin/cinder-scheduler", line 50, in <module>
  2013-06-27 15:05:30.257 TRACE cinder     service.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 624, in wait
  2013-06-27 15:05:30.257 TRACE cinder     _launcher.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 135, in wait
  2013-06-27 15:05:30.257 TRACE cinder     service.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 168, in wait
  2013-06-27 15:05:30.257 TRACE cinder     return self._exit_event.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/event.py", line 116, in wait
  2013-06-27 15:05:30.257 TRACE cinder     return hubs.get_hub().switch()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 187, in switch
  2013-06-27 15:05:30.257 TRACE cinder     return self.greenlet.switch()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 194, in main
  2013-06-27 15:05:30.257 TRACE cinder     result = function(*args, **kwargs)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 96, in run_server
  2013-06-27 15:05:30.257 TRACE cinder     server.start()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 359, in start
  2013-06-27 15:05:30.257 TRACE cinder     self.manager.init_host()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/scheduler/manager.py", line 62, in init_host
  2013-06-27 15:05:30.257 TRACE cinder     self.request_service_capabilities(ctxt)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/scheduler/manager.py", line 141, in request_service_capabilities
  2013-06-27 15:05:30.257 TRACE cinder     volume_rpcapi.VolumeAPI().publish_service_capabilities(context)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/volume/rpcapi.py", line 133, in publish_service_capabilities
  2013-06-27 15:05:30.257 TRACE cinder     version='1.2')
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/proxy.py", line 142, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     rpc.fanout_cast(context, self._get_topic(topic), msg)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/__init__.py", line 179, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     return _get_impl().fanout_cast(CONF, context, topic, msg)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 812, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     rpc_amqp.get_connection_pool(conf, Connection))
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 635, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     with ConnectionContext(conf, connection_pool) as conn:
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 122, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.connection = connection_pool.get()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/pools.py", line 119, in get
  2013-06-27 15:05:30.257 TRACE cinder     created = self.create()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 76, in create
  2013-06-27 15:05:30.257 TRACE cinder     return self.connection_cls(self.conf)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 447, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.reconnect()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 519, in reconnect
  2013-06-27 15:05:30.257 TRACE cinder     self._connect(params)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 495, in _connect
  2013-06-27 15:05:30.257 TRACE cinder     self.connection.connect()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 246, in connect
  2013-06-27 15:05:30.257 TRACE cinder     return self.connection
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 761, in connection
  2013-06-27 15:05:30.257 TRACE cinder     self._connection = self._establish_connection()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 720, in _establish_connection
  2013-06-27 15:05:30.257 TRACE cinder     conn = self.transport.establish_connection()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/transport/pyamqp.py", line 110, in establish_connection
  2013-06-27 15:05:30.257 TRACE cinder     **conninfo.transport_options or {})
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/connection.py", line 136, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.transport = create_transport(host, connect_timeout, ssl)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 252, in create_transport
  2013-06-27 15:05:30.257 TRACE cinder     return SSLTransport(host, connect_timeout, ssl)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 170, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     super(SSLTransport, self).__init__(host, connect_timeout)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 105, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self._setup_transport()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 178, in _setup_transport
  2013-06-27 15:05:30.257 TRACE cinder     self.sslobj = ssl.wrap_socket(self.sock, **self.sslopts)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/green/ssl.py", line 288, in wrap_socket
  2013-06-27 15:05:30.257 TRACE cinder     return GreenSSLSocket(sock, *a, **kw)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/green/ssl.py", line 46, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     super(GreenSSLSocket, self).__init__(sock.fd, *args, **kw)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/ssl.py", line 197, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     ciphers)
  2013-06-27 15:05:30.257 TRACE cinder TypeError: an integer is required

  This is because the underlying rpc driver is trying to create an SSL
  socket which requires an integer such as the following built-in SSL
  integer constants:

  PROTOCOL_SSLv2
  PROTOCOL_SSLv3
  PROTOCOL_SSLv23
  PROTOCOL_TLSv1

To manage notifications about this bug go to:
https://bugs.launchpad.net/oslo/+bug/1195431/+subscriptions



From davanum at gmail.com  Tue Jul  2 13:12:38 2013
From: davanum at gmail.com (Davanum Srinivas (DIMS))
Date: Tue, 02 Jul 2013 13:12:38 -0000
Subject: [Openstack-security] [Bug 1195431] Re: kombu_ssl_version is a
	cfg.StrOpt but the ssl	socket code requires an Integer value
References: <20130627190934.25966.77326.malonedeb@soybean.canonical.com>
Message-ID: <20130702131240.24125.24669.launchpad@soybean.canonical.com>

** Changed in: oslo
    Milestone: None => havana-2

** Changed in: oslo
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1195431

Title:
  kombu_ssl_version is a cfg.StrOpt but the ssl socket code requires an
  Integer value

Status in Oslo - a Library of Common OpenStack Code:
  In Progress

Bug description:
  When specifying 'kombu_ssl_version' for the RPC driver such as either
  "kombu_ssl_version=3" or "kombu_ssl_version=SSLv3" the relevant
  OpenStack service (nova, cinder, etc) will fail with the following
  traceback:

  2013-06-27 15:05:30.257 CRITICAL cinder [-] an integer is required
  2013-06-27 15:05:30.257 TRACE cinder Traceback (most recent call last):
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/bin/cinder-scheduler", line 50, in <module>
  2013-06-27 15:05:30.257 TRACE cinder     service.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 624, in wait
  2013-06-27 15:05:30.257 TRACE cinder     _launcher.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 135, in wait
  2013-06-27 15:05:30.257 TRACE cinder     service.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 168, in wait
  2013-06-27 15:05:30.257 TRACE cinder     return self._exit_event.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/event.py", line 116, in wait
  2013-06-27 15:05:30.257 TRACE cinder     return hubs.get_hub().switch()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 187, in switch
  2013-06-27 15:05:30.257 TRACE cinder     return self.greenlet.switch()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 194, in main
  2013-06-27 15:05:30.257 TRACE cinder     result = function(*args, **kwargs)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 96, in run_server
  2013-06-27 15:05:30.257 TRACE cinder     server.start()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 359, in start
  2013-06-27 15:05:30.257 TRACE cinder     self.manager.init_host()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/scheduler/manager.py", line 62, in init_host
  2013-06-27 15:05:30.257 TRACE cinder     self.request_service_capabilities(ctxt)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/scheduler/manager.py", line 141, in request_service_capabilities
  2013-06-27 15:05:30.257 TRACE cinder     volume_rpcapi.VolumeAPI().publish_service_capabilities(context)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/volume/rpcapi.py", line 133, in publish_service_capabilities
  2013-06-27 15:05:30.257 TRACE cinder     version='1.2')
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/proxy.py", line 142, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     rpc.fanout_cast(context, self._get_topic(topic), msg)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/__init__.py", line 179, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     return _get_impl().fanout_cast(CONF, context, topic, msg)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 812, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     rpc_amqp.get_connection_pool(conf, Connection))
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 635, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     with ConnectionContext(conf, connection_pool) as conn:
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 122, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.connection = connection_pool.get()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/pools.py", line 119, in get
  2013-06-27 15:05:30.257 TRACE cinder     created = self.create()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 76, in create
  2013-06-27 15:05:30.257 TRACE cinder     return self.connection_cls(self.conf)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 447, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.reconnect()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 519, in reconnect
  2013-06-27 15:05:30.257 TRACE cinder     self._connect(params)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 495, in _connect
  2013-06-27 15:05:30.257 TRACE cinder     self.connection.connect()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 246, in connect
  2013-06-27 15:05:30.257 TRACE cinder     return self.connection
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 761, in connection
  2013-06-27 15:05:30.257 TRACE cinder     self._connection = self._establish_connection()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 720, in _establish_connection
  2013-06-27 15:05:30.257 TRACE cinder     conn = self.transport.establish_connection()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/transport/pyamqp.py", line 110, in establish_connection
  2013-06-27 15:05:30.257 TRACE cinder     **conninfo.transport_options or {})
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/connection.py", line 136, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.transport = create_transport(host, connect_timeout, ssl)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 252, in create_transport
  2013-06-27 15:05:30.257 TRACE cinder     return SSLTransport(host, connect_timeout, ssl)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 170, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     super(SSLTransport, self).__init__(host, connect_timeout)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 105, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self._setup_transport()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 178, in _setup_transport
  2013-06-27 15:05:30.257 TRACE cinder     self.sslobj = ssl.wrap_socket(self.sock, **self.sslopts)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/green/ssl.py", line 288, in wrap_socket
  2013-06-27 15:05:30.257 TRACE cinder     return GreenSSLSocket(sock, *a, **kw)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/green/ssl.py", line 46, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     super(GreenSSLSocket, self).__init__(sock.fd, *args, **kw)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/ssl.py", line 197, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     ciphers)
  2013-06-27 15:05:30.257 TRACE cinder TypeError: an integer is required

  This is because the underlying rpc driver is trying to create an SSL
  socket which requires an integer such as the following built-in SSL
  integer constants:

  PROTOCOL_SSLv2
  PROTOCOL_SSLv3
  PROTOCOL_SSLv23
  PROTOCOL_TLSv1

To manage notifications about this bug go to:
https://bugs.launchpad.net/oslo/+bug/1195431/+subscriptions



From robert.clark at hp.com  Tue Jul  2 14:48:35 2013
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 2 Jul 2013 14:48:35 +0000
Subject: [Openstack-security] [OSSN] Draft: Nova Baremetal Exposes Previous
	Tenant Data
Message-ID: <CDF8A6D0.171F3%robert.clark@hp.com>

Nova Baremetal Exposes Previous Tenant Data
-----

### Summary ###
Data of previous tenants may be exposed to new ones when using Nova Baremetal

### Affected Services / Software ###
Keystone, Databases

### Discussion ###
Nova Baremetal is intended for testing and development only, it is not intended to be production ready. Experience has shown that despite that warning the OpenStack community is keen to embrace new technologies and deploy at-risk. This OSSN serves to signpost some of the risks.

Without secure boot, and without full openflow hardware networking during the boot process, it is impossible to trust multiple tenants on baremetal at all - because the vectors for attack are so low level that instances may be running in a virtual environment and unaware of it, with the virtual environment capturing secrets, forcing entropy pools to be predictable and other such hostile behaviour.

### Recommended Actions ###
Do not use Nova Baremetal where secure separation of tenants on hardware is a requirement without a full verifiable boot chain and network hardware.

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1174153
OpenStack Security ML : openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>
OpenStack Security Group : https://launchpad.net/~openstack-ossg



From kseifried at redhat.com  Tue Jul  2 16:48:55 2013
From: kseifried at redhat.com (Kurt Seifried)
Date: Tue, 02 Jul 2013 10:48:55 -0600
Subject: [Openstack-security] [OSSN] Draft: Nova Baremetal Exposes
 Previous Tenant Data
In-Reply-To: <CDF8A6D0.171F3%robert.clark@hp.com>
References: <CDF8A6D0.171F3%robert.clark@hp.com>
Message-ID: <51D30477.9000502@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/02/2013 08:48 AM, Clark, Robert Graham wrote:
> Nova Baremetal Exposes Previous Tenant Data -----
> 
> ### Summary ### Data of previous tenants may be exposed to new ones
> when using Nova Baremetal
> 
> ### Affected Services / Software ### Keystone, Databases
> 
> ### Discussion ### Nova Baremetal is intended for testing and
> development only, it is not intended to be production ready.
> Experience has shown that despite that warning the OpenStack
> community is keen to embrace new technologies and deploy at-risk.
> This OSSN serves to signpost some of the risks.
> 
> Without secure boot, and without full openflow hardware networking
> during the boot process, it is impossible to trust multiple tenants
> on baremetal at all - because the vectors for attack are so low
> level that instances may be running in a virtual environment and
> unaware of it, with the virtual environment capturing secrets,
> forcing entropy pools to be predictable and other such hostile
> behaviour.
> 
> ### Recommended Actions ### Do not use Nova Baremetal where secure
> separation of tenants on hardware is a requirement without a full
> verifiable boot chain and network hardware.
> 
> ### Contacts / References ### This OSSN :
> https://bugs.launchpad.net/ossn/+bug/1174153 OpenStack Security ML
> :
> openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>
>
> 
OpenStack Security Group : https://launchpad.net/~openstack-ossg
> 
> _______________________________________________ Openstack-security
> mailing list Openstack-security at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
> 
This sounds liek it needs  a CVE #. Any reason it wasn't given one?

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJR0wR3AAoJEBYNRVNeJnmT8cMP/jkX5Gl4JSLUiowRl5b3P2PD
Uadq4TLpw0Yc3FsOEBFId4KivmZhq9uY5jtzIQ+fzzy7DzAp+X5pWmeVhP7dRofO
11eGN/XnhfJKH8d5AmS0UlsPI0Fum88YLAU3tIczE0zeKrOopudwwZKL9URGVDao
XjP7P5pCw2uKxEME+zvHEydMNv9Dg/sv9D8W62q9CGLweY031WcnuSU6x81B5nRC
N3I+k8MCQjE1QVk9UWOZa3Dnb91wR3a0FcZZZDpHt9/KilZcPo7qg/T9IxM+Akz9
xSX8INm+4rRCfjC4Qzy4H9wHeHxZCG5sLvMpFzLDhhnhy4QwF6ej9wJKImO6VbB3
/OBRnc3yWWgLuZoW1X9dVNbWh5ju/NU/ZpfrfvumrAOyctIpD2bttJH48L47QIZi
6xI0T+TIUpFs8fnNXPD8UfhlOn9zck5USb+iTANzhYx4WSNiSzz+UudbSlfPWO0R
FNexQn3m74HmJUWuFtr4dC38FJAb476I+vsAoLtItJno6EwfvEUu5d7mRS2FqGq8
XrCAQccp+Qp5vBB2Oknk2ckJ0nys+901+ODybm6Va1yLvFS8EFTE5g1woReD7Yp4
1fPCUdETfnlUnSqS/ie924EvV2omAEn+Bdm8ZkE2SHdxXwsIRKiOeC85PN0rSbmF
+W9Slud4IuCCraHdh96g
=hWQ8
-----END PGP SIGNATURE-----



From fungi at yuggoth.org  Tue Jul  2 18:24:25 2013
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 2 Jul 2013 18:24:25 +0000
Subject: [Openstack-security] [OSSN] Draft: Nova Baremetal Exposes
 Previous Tenant Data
In-Reply-To: <51D30477.9000502@redhat.com>
References: <CDF8A6D0.171F3%robert.clark@hp.com> <51D30477.9000502@redhat.com>
Message-ID: <20130702182424.GF1472@yuggoth.org>

On 2013-07-02 10:48:55 -0600 (-0600), Kurt Seifried wrote:
> This sounds liek it needs a CVE #. Any reason it wasn't given one?

As far as I'm aware, these were known shortcomings of the design
before any of it was ever implemented, and it is still considered a
proof-of-concept without any enforced isolation or secure booting
solutions added yet. I suppose it could be argued whether a CVE
should have been requested before the software was ever written.
-- 
Jeremy Stanley



From gerrit2 at review.openstack.org  Tue Jul  2 18:26:38 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 02 Jul 2013 18:26:38 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I358813b3ecde4f88de7202c1c07d9b1168c2c332
Message-ID: <E1Uu5Hi-0006xi-Vw@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/30976

Log:
commit 68052f03143811a0f5b7edb42cd8fd4578212224
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Tue Jul 2 12:32:48 2013 -0400

    Add encryption support for volumes
    
    Add support to encrypt Cinder volumes. Modified the libvirt driver to encrypt
    volumes during the attach call. Created a new VolumeEncryptor class that is
    responsible for encrypting volumes. The default implementation does not do
    enryption, and a DmCryptVolumeEncryptor is provided to encrypt volumes using
    dmcrypt.
    
    This feature requires related changes within Cinder (e.g., storing encryption
    key UUIDs for encrypted volumes), which have not yet been accepted. This patch
    is fully functional but is will require further modifications (that are
    relatively minor) once the related Cinder changes have been accepted.
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I358813b3ecde4f88de7202c1c07d9b1168c2c332
    SecurityImpact




From kseifried at redhat.com  Tue Jul  2 18:53:34 2013
From: kseifried at redhat.com (Kurt Seifried)
Date: Tue, 02 Jul 2013 12:53:34 -0600
Subject: [Openstack-security] [OSSN] Draft: Nova Baremetal Exposes
 Previous Tenant Data
In-Reply-To: <20130702182424.GF1472@yuggoth.org>
References: <CDF8A6D0.171F3%robert.clark@hp.com> <51D30477.9000502@redhat.com>
 <20130702182424.GF1472@yuggoth.org>
Message-ID: <51D321AE.8080800@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/02/2013 12:24 PM, Jeremy Stanley wrote:
> On 2013-07-02 10:48:55 -0600 (-0600), Kurt Seifried wrote:
>> This sounds liek it needs a CVE #. Any reason it wasn't given
>> one?
> 
> As far as I'm aware, these were known shortcomings of the design 
> before any of it was ever implemented, and it is still considered
> a proof-of-concept without any enforced isolation or secure
> booting solutions added yet. I suppose it could be argued whether a
> CVE should have been requested before the software was ever
> written.
> 

Huh? According to: https://wiki.openstack.org/wiki/Baremetal

"This driver was added to the Grizzly release, but it should be
considered somewhat experimental at this point. See the Bugs section
for information and links to the Launchpad bug listings."

also no mention of any security issues with respect to data not being
wiped. Now I get that the software hasn't been officially blessed as
production ready, but it has been released publicly. Unless there isa
compelling reason not to assign a CVE for this (speak up now!) I'll do
so later today.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJR0yGuAAoJEBYNRVNeJnmTeqMP/AwZ8LVlswnQxcaS69WO6g74
wFM1CIRA7lax0W6nuZmQTcxXCqajwDyYoOoT4NiKQGXHKvWh0I47Edki+GVFAXDP
5PoT5GjLB3IR6OkMHqQkiKyzLOrJkcH7v+gfqNtoniuJ+vvozFLGghfEkzknCoPX
orCfyDKCd5bow3nqyMQw3uIdBXnlRabl7vpyEPq3x+GLswElC9mW1RzEC6HK2gm7
gmFf7cAFyCkdpYzeP2XD19bOeyeEVJEadHTh15BpgRQJ0UvotYlsmgnx4g7iIu3A
JU9L6dfVFQHWZr+2x4kLzFZC3xzB4wsPGGK0Rh6/gj4ddLuZkLFIEcvYvFTtb4Fl
8m3DvCNWoRT09W6A5G16ED54AL6dan3s8CyhmpzzWABrAXTasenGKbV20cSwbzA4
xOYjEqFvfnAEZN0xgdblZC6cpbZCd6yl7CxBWhvC/xnDOwVtye6wmmcye8Mt1gaB
ML3BAO7AsPyB2WNWaHW09xC62e54YnteXEC+6hFJMAwhUUdJJ352jDExuRk2wTQJ
4dMqpnmTsTtN7fkBnJdLPQk2pfrWowdy2fZFzSGervErYLHORjIkcoI0eObj/U2n
Zss9t5csnCpzUTKnYQY4fyRSgUkRteKhAtEVwvLN/cnYRZlyMoK4lab6mW/6j05X
Ptiamk8qOrG2/G4RCpC3
=tMq5
-----END PGP SIGNATURE-----



From fungi at yuggoth.org  Tue Jul  2 19:06:18 2013
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 2 Jul 2013 19:06:18 +0000
Subject: [Openstack-security] [OSSN] Draft: Nova Baremetal Exposes
 Previous Tenant Data
In-Reply-To: <51D321AE.8080800@redhat.com>
References: <CDF8A6D0.171F3%robert.clark@hp.com> <51D30477.9000502@redhat.com>
 <20130702182424.GF1472@yuggoth.org> <51D321AE.8080800@redhat.com>
Message-ID: <20130702190616.GG1472@yuggoth.org>

On 2013-07-02 12:53:34 -0600 (-0600), Kurt Seifried wrote:
> Huh? According to: https://wiki.openstack.org/wiki/Baremetal
> 
> "This driver was added to the Grizzly release, but it should be
> considered somewhat experimental at this point. See the Bugs section
> for information and links to the Launchpad bug listings."
> 
> also no mention of any security issues with respect to data not being
> wiped. Now I get that the software hasn't been officially blessed as
> production ready, but it has been released publicly. Unless there isa
> compelling reason not to assign a CVE for this (speak up now!) I'll do
> so later today.

I agree it's unfortunate if security precautions weren't spelled out
in the release notes, so if that qualifies for a CVE then it sounds
like we probably do need one. In your opinion would it have needed a
CVE if the situation were spelled out in the release notes already?

I suppose this drives to a process question for us as a project,
whether we can actually develop work-in-progress/experimental
features in-tree with a timed release schedule, knowing that we may
need to consider either (dangerously) ripping them back out at
release time or announcing known security vulnerabilities in them at
release time instead.
-- 
Jeremy Stanley



From kseifried at redhat.com  Tue Jul  2 19:15:27 2013
From: kseifried at redhat.com (Kurt Seifried)
Date: Tue, 02 Jul 2013 13:15:27 -0600
Subject: [Openstack-security] [OSSN] Draft: Nova Baremetal Exposes
 Previous Tenant Data
In-Reply-To: <20130702190616.GG1472@yuggoth.org>
References: <CDF8A6D0.171F3%robert.clark@hp.com> <51D30477.9000502@redhat.com>
 <20130702182424.GF1472@yuggoth.org> <51D321AE.8080800@redhat.com>
 <20130702190616.GG1472@yuggoth.org>
Message-ID: <51D326CF.2030808@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/02/2013 01:06 PM, Jeremy Stanley wrote:
> On 2013-07-02 12:53:34 -0600 (-0600), Kurt Seifried wrote:
>> Huh? According to: https://wiki.openstack.org/wiki/Baremetal
>> 
>> "This driver was added to the Grizzly release, but it should be 
>> considered somewhat experimental at this point. See the Bugs
>> section for information and links to the Launchpad bug
>> listings."
>> 
>> also no mention of any security issues with respect to data not
>> being wiped. Now I get that the software hasn't been officially
>> blessed as production ready, but it has been released publicly.
>> Unless there isa compelling reason not to assign a CVE for this
>> (speak up now!) I'll do so later today.
> 
> I agree it's unfortunate if security precautions weren't spelled
> out in the release notes, so if that qualifies for a CVE then it
> sounds like we probably do need one. In your opinion would it have
> needed a CVE if the situation were spelled out in the release notes
> already?

If the documentation specifically said "WARNING: DATA MAY BE EXPOSED
DUE TO LACK OF WIPING" then no CVE most likely. It's a continuum, but
basically some examples:

=======================
http://seclists.org/oss-sec/2013/q1/155

Further note, for example:

A default account/password in a device or service. Is this a security
issue or not? Different scenarios have different outcomes:

1) The default account/password is well documented. The services
forces you to change the password when first run and will refuse to
run until you do change the password. Generally not considered a vuln.

2) The default account/password is well documented. The services does
not force you to change the password when first run. Generally not
considered a vuln as it falls into the "don't do stupid things" class
of issues.

3) The default account/password is not well documented or not
documented at all but can be changed. Generally this would be
considered a vulnerability.

4) The default account/password is not well documented or not
documented at all and can NOT be changed. Generally this would be
considered a vulnerability.

Similar things for other things, is it a security vulnerability or
security hardening, or not a security issue at all? It definitely gets
fuzzy/messy sometimes.
=======================

So this looks like a #4, not documented, not something that can easily
be fixed by the user.

> I suppose this drives to a process question for us as a project, 
> whether we can actually develop work-in-progress/experimental 
> features in-tree with a timed release schedule, knowing that we
> may need to consider either (dangerously) ripping them back out at 
> release time or announcing known security vulnerabilities in them
> at release time instead.

That is a good question. One thing that might be helpful is to mark
such code as experimental/dangerous/may eat all your datas and include
any potential gotchas to warn people about, which is probably a good
idea either way as it would reduce risk, or if not that at least let
people make informed decisions about the risk they are taking.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJR0ybPAAoJEBYNRVNeJnmTMOMQAJnhG3tJ/6AoM7wptHLYT+P0
k1RAILsNqWsK213IqL+mpnVlVMqj4NllJyokSejbfywTaFpw0kq9il4BHmr/5k9F
BeXJLBjUicuqaylyTp+dQbKADgViIpAuw703RTO5Irumugmrqcr/Pj6a2e4JGeY9
d6MN0plPEaiKSNUX4H/wyqthzwpfx1OIv9BHhY1geHgZUpxsLGeE0aGxGab91Vwv
SPetHIpB9QqzV9TKFWvTDPWxFU2xU/56mEe/WOqCRdrSh29/ki3zisdCAyvM2ry/
14pDWKFKJDY7OiKx9OnbSFeGf7mH6Si8YfAOxeQU+fe39dPMaZJNxY415pE8Zh0F
p5RWZ7mTGkxGwemk2E11ODUKM9iKmJuWaE8pgIGEVncoJqOLiFCPU5wl97zChHeq
Xiz//CYS7ZklMuvboxIM8knp9eHdFpiLp2h4ELDCNHv807uYNaWptRvlP1Zhyq9u
obqLQP/V9Bb/2HSmqLbOpVsacIZp/BQY/cnjCGERwMA17psY1ggl8NT89exSjop9
jXonYuNoe21Z5Fjh+C50hkBpREBKXTcgk2jKpX2+dSLz/M0japctKCoguc2yCGWl
nzrNLi9l87i/d9bintdMdX/qhREwwb938xnvkfVRFc05XTqEcm+vrLLu0Y5pW76K
G0Hh7vc2TXLY3OygOygX
=lC0m
-----END PGP SIGNATURE-----



From robert.clark at hp.com  Wed Jul  3 06:41:42 2013
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 3 Jul 2013 06:41:42 +0000
Subject: [Openstack-security] [OSSN] Draft: Nova Baremetal Exposes
 Previous Tenant Data
In-Reply-To: <51D326CF.2030808@redhat.com>
Message-ID: <CDF985D3.172D3%robert.clark@hp.com>

So I think two things probably need to happen here. One is a further
discussion on how 'dangerous' code should be tagged in future, the second
is if this needs a CVE.

In regard to the latter I don't think there's a big reason _NOT_ to cut a
CVE but I'm not passionate about it either way. What I would like is some
agreement so if there is a CVE I can reference it in the OSSN and if there
isn't I can just go ahead and publish.

Cheers
-Rob

On 02/07/2013 20:15, "Kurt Seifried" <kseifried at redhat.com> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 07/02/2013 01:06 PM, Jeremy Stanley wrote:
>> On 2013-07-02 12:53:34 -0600 (-0600), Kurt Seifried wrote:
>>> Huh? According to: https://wiki.openstack.org/wiki/Baremetal
>>> 
>>> "This driver was added to the Grizzly release, but it should be
>>> considered somewhat experimental at this point. See the Bugs
>>> section for information and links to the Launchpad bug
>>> listings."
>>> 
>>> also no mention of any security issues with respect to data not
>>> being wiped. Now I get that the software hasn't been officially
>>> blessed as production ready, but it has been released publicly.
>>> Unless there isa compelling reason not to assign a CVE for this
>>> (speak up now!) I'll do so later today.
>> 
>> I agree it's unfortunate if security precautions weren't spelled
>> out in the release notes, so if that qualifies for a CVE then it
>> sounds like we probably do need one. In your opinion would it have
>> needed a CVE if the situation were spelled out in the release notes
>> already?
>
>If the documentation specifically said "WARNING: DATA MAY BE EXPOSED
>DUE TO LACK OF WIPING" then no CVE most likely. It's a continuum, but
>basically some examples:
>
>=======================
>http://seclists.org/oss-sec/2013/q1/155
>
>Further note, for example:
>
>A default account/password in a device or service. Is this a security
>issue or not? Different scenarios have different outcomes:
>
>1) The default account/password is well documented. The services
>forces you to change the password when first run and will refuse to
>run until you do change the password. Generally not considered a vuln.
>
>2) The default account/password is well documented. The services does
>not force you to change the password when first run. Generally not
>considered a vuln as it falls into the "don't do stupid things" class
>of issues.
>
>3) The default account/password is not well documented or not
>documented at all but can be changed. Generally this would be
>considered a vulnerability.
>
>4) The default account/password is not well documented or not
>documented at all and can NOT be changed. Generally this would be
>considered a vulnerability.
>
>Similar things for other things, is it a security vulnerability or
>security hardening, or not a security issue at all? It definitely gets
>fuzzy/messy sometimes.
>=======================
>
>So this looks like a #4, not documented, not something that can easily
>be fixed by the user.
>
>> I suppose this drives to a process question for us as a project,
>> whether we can actually develop work-in-progress/experimental
>> features in-tree with a timed release schedule, knowing that we
>> may need to consider either (dangerously) ripping them back out at
>> release time or announcing known security vulnerabilities in them
>> at release time instead.
>
>That is a good question. One thing that might be helpful is to mark
>such code as experimental/dangerous/may eat all your datas and include
>any potential gotchas to warn people about, which is probably a good
>idea either way as it would reduce risk, or if not that at least let
>people make informed decisions about the risk they are taking.
>
>- -- 
>Kurt Seifried Red Hat Security Response Team (SRT)
>PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.13 (GNU/Linux)
>
>iQIcBAEBAgAGBQJR0ybPAAoJEBYNRVNeJnmTMOMQAJnhG3tJ/6AoM7wptHLYT+P0
>k1RAILsNqWsK213IqL+mpnVlVMqj4NllJyokSejbfywTaFpw0kq9il4BHmr/5k9F
>BeXJLBjUicuqaylyTp+dQbKADgViIpAuw703RTO5Irumugmrqcr/Pj6a2e4JGeY9
>d6MN0plPEaiKSNUX4H/wyqthzwpfx1OIv9BHhY1geHgZUpxsLGeE0aGxGab91Vwv
>SPetHIpB9QqzV9TKFWvTDPWxFU2xU/56mEe/WOqCRdrSh29/ki3zisdCAyvM2ry/
>14pDWKFKJDY7OiKx9OnbSFeGf7mH6Si8YfAOxeQU+fe39dPMaZJNxY415pE8Zh0F
>p5RWZ7mTGkxGwemk2E11ODUKM9iKmJuWaE8pgIGEVncoJqOLiFCPU5wl97zChHeq
>Xiz//CYS7ZklMuvboxIM8knp9eHdFpiLp2h4ELDCNHv807uYNaWptRvlP1Zhyq9u
>obqLQP/V9Bb/2HSmqLbOpVsacIZp/BQY/cnjCGERwMA17psY1ggl8NT89exSjop9
>jXonYuNoe21Z5Fjh+C50hkBpREBKXTcgk2jKpX2+dSLz/M0japctKCoguc2yCGWl
>nzrNLi9l87i/d9bintdMdX/qhREwwb938xnvkfVRFc05XTqEcm+vrLLu0Y5pW76K
>G0Hh7vc2TXLY3OygOygX
>=lC0m
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security




From kseifried at redhat.com  Wed Jul  3 07:37:20 2013
From: kseifried at redhat.com (Kurt Seifried)
Date: Wed, 03 Jul 2013 01:37:20 -0600
Subject: [Openstack-security] [OSSN] Draft: Nova Baremetal Exposes
 Previous Tenant Data
In-Reply-To: <CDF985D3.172D3%robert.clark@hp.com>
References: <CDF985D3.172D3%robert.clark@hp.com>
Message-ID: <51D3D4B0.2020504@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/03/2013 12:41 AM, Clark, Robert Graham wrote:
> So I think two things probably need to happen here. One is a
> further discussion on how 'dangerous' code should be tagged in
> future, the second is if this needs a CVE.
> 
> In regard to the latter I don't think there's a big reason _NOT_ to
> cut a CVE but I'm not passionate about it either way. What I would
> like is some agreement so if there is a CVE I can reference it in
> the OSSN and if there isn't I can just go ahead and publish.

Since no-one seems to object, and we have a history of cve's for not
wiping disk before usage in these kinds of situations please use
CVE-2013-2235 for this issue.

> 
> Cheers -Rob
> 
> On 02/07/2013 20:15, "Kurt Seifried" <kseifried at redhat.com> wrote:
> 
> On 07/02/2013 01:06 PM, Jeremy Stanley wrote:
>>>> On 2013-07-02 12:53:34 -0600 (-0600), Kurt Seifried wrote:
>>>>> Huh? According to:
>>>>> https://wiki.openstack.org/wiki/Baremetal
>>>>> 
>>>>> "This driver was added to the Grizzly release, but it
>>>>> should be considered somewhat experimental at this point.
>>>>> See the Bugs section for information and links to the
>>>>> Launchpad bug listings."
>>>>> 
>>>>> also no mention of any security issues with respect to data
>>>>> not being wiped. Now I get that the software hasn't been
>>>>> officially blessed as production ready, but it has been
>>>>> released publicly. Unless there isa compelling reason not
>>>>> to assign a CVE for this (speak up now!) I'll do so later
>>>>> today.
>>>> 
>>>> I agree it's unfortunate if security precautions weren't
>>>> spelled out in the release notes, so if that qualifies for a
>>>> CVE then it sounds like we probably do need one. In your
>>>> opinion would it have needed a CVE if the situation were
>>>> spelled out in the release notes already?
> 
> If the documentation specifically said "WARNING: DATA MAY BE
> EXPOSED DUE TO LACK OF WIPING" then no CVE most likely. It's a
> continuum, but basically some examples:
> 
> ======================= http://seclists.org/oss-sec/2013/q1/155
> 
> Further note, for example:
> 
> A default account/password in a device or service. Is this a
> security issue or not? Different scenarios have different
> outcomes:
> 
> 1) The default account/password is well documented. The services 
> forces you to change the password when first run and will refuse
> to run until you do change the password. Generally not considered a
> vuln.
> 
> 2) The default account/password is well documented. The services
> does not force you to change the password when first run. Generally
> not considered a vuln as it falls into the "don't do stupid things"
> class of issues.
> 
> 3) The default account/password is not well documented or not 
> documented at all but can be changed. Generally this would be 
> considered a vulnerability.
> 
> 4) The default account/password is not well documented or not 
> documented at all and can NOT be changed. Generally this would be 
> considered a vulnerability.
> 
> Similar things for other things, is it a security vulnerability or 
> security hardening, or not a security issue at all? It definitely
> gets fuzzy/messy sometimes. =======================
> 
> So this looks like a #4, not documented, not something that can
> easily be fixed by the user.
> 
>>>> I suppose this drives to a process question for us as a
>>>> project, whether we can actually develop
>>>> work-in-progress/experimental features in-tree with a timed
>>>> release schedule, knowing that we may need to consider either
>>>> (dangerously) ripping them back out at release time or
>>>> announcing known security vulnerabilities in them at release
>>>> time instead.
> 
> That is a good question. One thing that might be helpful is to
> mark such code as experimental/dangerous/may eat all your datas and
> include any potential gotchas to warn people about, which is
> probably a good idea either way as it would reduce risk, or if not
> that at least let people make informed decisions about the risk
> they are taking.
> 
>> 
>> _______________________________________________ 
>> Openstack-security mailing list 
>> Openstack-security at lists.openstack.org 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>> 
- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJR09SwAAoJEBYNRVNeJnmTvKUP/AqlQ1xXuTz3SQymNsgCauTF
j6ApQ5B+X8AOl7ugmVMe/01rbiiMPb6P3mb2fLZyDCJ9uZjnuWw+xeFUd8GbWcCN
2mFGWCl/CpShUXe1NnH5emfs2Jx/a99dw8nmsPtStk2H/tu3PUkrUQF2WYYFDhDB
VcOIHim+HiBLLmKAzIgHDEA79Et18o7O3OqgCx3OtlpTxBtIQWiQGWVy1cdP8iBm
Ab52Tr9bvqj/QHMo2U7mcnlx40/FYJcQWjJs6jKva4VhzEdXwX0u2rymjTgi2hY4
kXwwEJX33qmsTHbSuRdtZcmDAhEf31oX8J60rdOFY1bq3hIJSPBBIaIBNM/BN9sD
540FvJBnWml+S2y1CTo+GnH3Xzcn2THd4uhjyo67ubuE2Ju9cqXFTypoXTJfR3NU
avL+9A9HReers5CXVLbLMDz50sj23/hQuJGnSp4gN53m8K9sI1kLM/3FpqR1OAIv
d0xI3yXG4EUPfG3oPVAMg1a+O4jlvOyY3B8zOOtozlqXgqOsbinqReyWKNeN/ZaS
MODOqfh9mPMkklN1EikrcJPFJJvo5mGNwmFiCTIIMbyex+bOs5+QM47SuPtsY3mY
S3nFDcEWXjwREyG2WZapJNYWUAtVxCrOxncWDgncS3DPbSINUxOcq+qF0cXut+H8
a6Yv7dz7n5MrrsC31Zjk
=ybb/
-----END PGP SIGNATURE-----



From gerrit2 at review.openstack.org  Wed Jul  3 20:38:39 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 03 Jul 2013 20:38:39 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I164290e761a9922919a70f22f99af70dac213b61
Message-ID: <E1UuTp1-0006F1-9T@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/30974

Log:
commit afe2f9614855964c232d7d10a22c1f0becb3b795
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Wed Jul 3 16:34:56 2013 -0400

    Add encryption metadata to volume table
    
    This modification adds an encryption key UUID field to the volume
    table, which is sufficient to make Cinder "aware" of encrypted volumes
    as designated by predefined volume types. Integration with a key
    manager is necessary to obtain an actual encryption key UUID (the
    current implementation generates a random UUID when an encrypted
    volumes is created). Cinder should *not* presume that it necessarily
    will have access to the key itself -- this decision depends upon the
    design, implementation, and policy for encrypted volumes. The key's
    UUID is stored in Cinder because it is metadata about the volume.
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I164290e761a9922919a70f22f99af70dac213b61
    SecurityImpact




From gerrit2 at review.openstack.org  Mon Jul  8 15:48:55 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 08 Jul 2013 15:48:55 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50
Message-ID: <E1UwDgN-0002IG-Gw@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/30973

Log:
commit 123611b45b472ee20fd3bae4cf240f4db704e84e
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Mon Jul 8 11:31:26 2013 -0400

    Create key manager interface
    
    This interface provides a thin wrapper around an underlying key management
    implementation such as Barbican or a KMIP server. The key manager interface is
    used by the volume encryption code to retrieve keys for volumes.
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50
    SecurityImpact




From gerrit2 at review.openstack.org  Mon Jul  8 17:18:45 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 08 Jul 2013 17:18:45 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I358813b3ecde4f88de7202c1c07d9b1168c2c332
Message-ID: <E1UwF5J-0000vk-DE@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/30976

Log:
commit 806dd03f6d2cd83328b70c04a28a793b15911ddd
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Mon Jul 8 13:14:39 2013 -0400

    Add encryption support for volumes
    
    Add support to encrypt Cinder volumes. Modified the libvirt driver to
    encrypt volumes during the attach call. Created a new VolumeEncryptor
    class that is responsible for encrypting volumes. The default
    implementation does not do enryption, and a DmCryptVolumeEncryptor is
    provided to encrypt volumes using dmcrypt.
    
    This feature requires related changes within Cinder (e.g., storing
    encryption key UUIDs for encrypted volumes), which have not yet been
    accepted. This patch is fully functional but requires further
    modifications (that are relatively minor) once the related Cinder
    changes have been accepted.
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I358813b3ecde4f88de7202c1c07d9b1168c2c332
    SecurityImpact




From gerrit2 at review.openstack.org  Mon Jul  8 21:25:56 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 08 Jul 2013 21:25:56 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I358813b3ecde4f88de7202c1c07d9b1168c2c332
Message-ID: <E1UwIwW-00045C-6v@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/30976

Log:
commit 30022e5ae4177270a85246e7c5ac72a52b73f333
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Mon Jul 8 13:14:39 2013 -0400

    Add encryption support for volumes
    
    Add support to encrypt Cinder volumes. Modified the libvirt driver to
    encrypt volumes during the attach call. Created a new VolumeEncryptor
    class that is responsible for encrypting volumes. The default
    implementation does not do enryption, and a DmCryptVolumeEncryptor is
    provided to encrypt volumes using dmcrypt.
    
    This feature requires related changes within Cinder (e.g., storing
    encryption key UUIDs for encrypted volumes), which have not yet been
    accepted. This patch is fully functional but requires further
    modifications (that are relatively minor) once the related Cinder
    changes have been accepted.
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I358813b3ecde4f88de7202c1c07d9b1168c2c332
    SecurityImpact




From 1074087 at bugs.launchpad.net  Tue Jul  9 15:20:26 2013
From: 1074087 at bugs.launchpad.net (OpenStack Hudson)
Date: Tue, 09 Jul 2013 15:20:26 -0000
Subject: [Openstack-security] [Bug 1074087] Re: XenApi migration driver
	should not use shell=True	with Popen
References: <20121101174933.5279.14962.malonedeb@gac.canonical.com>
Message-ID: <20130709152026.4417.99962.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/34580
Committed: http://github.com/openstack/nova/commit/61ef64f48f6815e6e6bb771d2fb33ddcf2f30f40
Submitter: Jenkins
Branch:    master

commit 61ef64f48f6815e6e6bb771d2fb33ddcf2f30f40
Author: Euan Harris <euan.harris at citrix.com>
Date:   Wed Jun 26 16:57:14 2013 +0100

    xenapi: Tidy up Popen calls to avoid command injection attacks
    
     * Rewrite xenhost._run_command and xenstore._run_command to use
       utils.make_subprocess and utils.finish_process
     * Change exception raised by utils.finish_process to retain information
       needed by calls in xenhost and xenstore
    
    Change-Id: Idcdb50bededf0acde92f1774d6752043ba8f97ce
    Fixes: bug #1074087


** Changed in: nova
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1074087

Title:
  XenApi migration driver should not use shell=True with Popen

Status in OpenStack Compute (Nova):
  Fix Committed

Bug description:
  The XenApi drivers split a string to create an array for
  subprocess.Popen, rather than passing an array directly. This invites
  the potential for command injection / manipulation.

  There is no clearly valid reason to use string splitting here when
  arguments can be passed, as elsewhere, directly into Popen.

  The behavior here is present in current Trunk, Folsom, and Essex.  Per
  Trunk and Folsom, _rsync_vhds calls plugins.utils.subprocess to
  perform the splitting.  In Essex, this behaviorism was present
  directly in migration/transfer_vhd.py, rather than in utils.py.
  Earlier releases have not been evaluated.

  I am not certain if this is directly exploitable. The user field is
  inserted into the generated strings used for command-line execution,
  and it does seem that Keystone allows usernames to contain arbitrary
  tokens/characters such as spaces.  It is not clear to me if the user
  field directly matches that in Keystone, if the user field is
  otherwise validated in the API, etc.  Other fields inserted into the
  command string seem to be internally generated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1074087/+subscriptions



From 1129748 at bugs.launchpad.net  Wed Jul 10 09:34:17 2013
From: 1129748 at bugs.launchpad.net (Xavier Queralt)
Date: Wed, 10 Jul 2013 09:34:17 -0000
Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should
	not be world-readable
References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com>
Message-ID: <20130710093417.22992.22780.malone@gac.canonical.com>

I don't see a clear solution for this problem in nova and I think this
could be better handled in the packaging.

When changing the mode of the instances' directory to 0760 we are also
preventing the user 'qemu' to access the images and other files we store
there (See nova-compute logs @ 2013-06-07 15:35:00.955 [1]).

>From libvirt's documentation [2]:

"The directories /var/run/libvirt/qemu/, /var/lib/libvirt/qemu/ and
/var/cache/libvirt/qemu/ must all have their ownership set to match the
user / group ID that QEMU guests will be run as. If the vendor has set a
non-root user/group for the QEMU driver at build time, the permissions
should be set automatically at install time. If a host administrator
customizes user/group in /etc/libvirt/qemu.conf, they will need to
manually set the ownership on these directories."

In Fedora and RedHat the QEMU guests run as qemu (group qemu) while in
debian and ubuntu they runs as libvirt-qemu (group kvm).

An easy solution would be to just change the group of the instances
directory to the one qemu is going to use (either qemu or kvm) while
still changing the permissions on that directory to 0760. And I'd
definitely do this on the packaging level.

Because, besides libvirt, is there any other virt driver storing images
in the instances directory?

[1] http://logs.openstack.org/32146/2/check/gate-tempest-devstack-vm-full/21468/logs/screen-n-cpu.txt.gz
[2] http://libvirt.org/drvqemu.html#securitydriver

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1129748

Title:
  image files in _base should not be world-readable

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 ,
  so probably no point making this private.  But I checked the security
  vulnerability box anyway so someone else can decide.

  We create image files in /var/lib/nova/instances/_base with default
  permissions, usually 644.  It would be better to not make the image
  files world-readable, in case they contain private data.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1129748/+subscriptions



From thierry.carrez+lp at gmail.com  Wed Jul 10 13:30:08 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 10 Jul 2013 13:30:08 -0000
Subject: [Openstack-security] [Bug 1197459] Re: noVNC contains the session
	token in URL and	insecurely sets the session cookie
References: <20130703161152.14968.85936.malonedeb@gac.canonical.com>
Message-ID: <20130710133010.22717.88825.launchpad@gac.canonical.com>

** Information type changed from Private Security to Public

** Tags added: security

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Changed in: nova
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1197459

Title:
  noVNC contains the session token in URL and insecurely sets the
  session cookie

Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The VNC Console connection in Nova works by having the user connect to
  the API which returns a URL such as:
  https://example.com:443/?token=abc Where the token has a TTL which is
  then used to create a session from a WebSocket. However, URL's should
  not contain sensitive information such as session tokens with a TTL
  since URL's can be leaked through proxy logs or other types of attacks
  such as Cross-Site Scripting. Additionally, due to the session cookie
  being set with JavaScript it cannot securely be set to HttpOnly nor is
  it set with the Secure flag making it further susceptible to Cross-
  Site Scripting attacks or leakage through a non-SSL connection. To
  limit the exposure of the token being leaked through the URL the
  returned token from the API should be of a one-time use and only used
  as an authentication token in order to obtain a session. The session
  cookie should be set by a Web Service instead of the client in order
  to securely set the cookie with the HttpOnly flag to be set in
  addition to setting the Secure flag.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1197459/+subscriptions



From thierry.carrez+lp at gmail.com  Wed Jul 10 13:33:36 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 10 Jul 2013 13:33:36 -0000
Subject: [Openstack-security] [Bug 1192971] Re: Command execution cases need
	to be strengthened
References: <20130620133506.19620.30523.malonedeb@gac.canonical.com>
Message-ID: <20130710133336.15911.21903.malone@chaenomeles.canonical.com>

Agreed, opening so that we can fix those in the open.

** Information type changed from Private Security to Public

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Tags added: security

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1192971

Title:
  Command execution cases need to be strengthened

Status in Cinder:
  Confirmed
Status in OpenStack Compute (Nova):
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Grant Murphy from Red Hat Product Security Team reports the following
  potential vulnerability:

  For the most part OpenStack seems to do command execution safely using
  subprocess.Popen. There are two instances where things become a little
  dubious. The first is when shell=True is used with subprocess. This
  doesn't prevent arguments being supplied that allow for multiple
  commands to be executed. e.g. '; cat /etc/passwd'. The second case is
  where commands are made to an external ssh host.

  See attached file for a lit of potential injections: we should double-
  check them (even if I expect most of them to turn false positive)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1192971/+subscriptions



From thierry.carrez+lp at gmail.com  Wed Jul 10 13:36:33 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 10 Jul 2013 13:36:33 -0000
Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL'
	communication fails to check	certificates (use of HTTPSConnection)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20130710133633.22784.915.malone@gac.canonical.com>

Ok, so we should:
* implement as a new feature in an upcoming version (the sooner the better)
* document as unsafe in previous versions (OSSN)

Any taker to work on that ?

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2013-2255

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Tags added: security

** Information type changed from Private Security to Public

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1188189

Title:
  Some server-side 'SSL' communication fails to check certificates (use
  of HTTPSConnection)

Status in Cinder:
  Confirmed
Status in OpenStack Identity (Keystone):
  Confirmed
Status in OpenStack Neutron (virtual network service):
  Confirmed
Status in OpenStack Compute (Nova):
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  In Progress
Status in Python client library for Keystone:
  Confirmed
Status in OpenStack Object Storage (Swift):
  Invalid

Bug description:
  Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection
  objects. In Python 2.x those do not perform CA checks so client
  connections are vulnerable to MiM attacks.

  """
  The following files use httplib.HTTPSConnection :
  keystone/middleware/s3_token.py
  keystone/middleware/ec2_token.py
  keystone/common/bufferedhttp.py
  vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py

  AFAICT HTTPSConnection does not validate server certificates and
  should be avoided. This is fixed in Python 3, however in 2.X no
  validation occurs. I suspect this is also applicable to most OpenStack
  modules that make HTTPS client calls.

  Similar problems were found in ovirt:
  https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533)

  With solutions for ovirt:
  http://gerrit.ovirt.org/#/c/7209/
  http://gerrit.ovirt.org/#/c/7249/
  """

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions



From jlennox at redhat.com  Wed Jul 10 22:54:33 2013
From: jlennox at redhat.com (Jamie Lennox)
Date: Wed, 10 Jul 2013 22:54:33 -0000
Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL'
	communication fails to check	certificates (use of HTTPSConnection)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20130710225435.16345.56289.malone@chaenomeles.canonical.com>

I've got a patch or two related to this waiting already

** Changed in: python-keystoneclient
     Assignee: (unassigned) => Jamie Lennox (jamielennox)

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1188189

Title:
  Some server-side 'SSL' communication fails to check certificates (use
  of HTTPSConnection)

Status in Cinder:
  Confirmed
Status in OpenStack Identity (Keystone):
  Confirmed
Status in OpenStack Neutron (virtual network service):
  Confirmed
Status in OpenStack Compute (Nova):
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  In Progress
Status in Python client library for Keystone:
  Confirmed
Status in OpenStack Object Storage (Swift):
  Invalid

Bug description:
  Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection
  objects. In Python 2.x those do not perform CA checks so client
  connections are vulnerable to MiM attacks.

  """
  The following files use httplib.HTTPSConnection :
  keystone/middleware/s3_token.py
  keystone/middleware/ec2_token.py
  keystone/common/bufferedhttp.py
  vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py

  AFAICT HTTPSConnection does not validate server certificates and
  should be avoided. This is fixed in Python 3, however in 2.X no
  validation occurs. I suspect this is also applicable to most OpenStack
  modules that make HTTPS client calls.

  Similar problems were found in ovirt:
  https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533)

  With solutions for ovirt:
  http://gerrit.ovirt.org/#/c/7209/
  http://gerrit.ovirt.org/#/c/7249/
  """

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions



From dripton at redhat.com  Wed Jul 10 14:21:11 2013
From: dripton at redhat.com (David Ripton)
Date: Wed, 10 Jul 2013 14:21:11 -0000
Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should
	not be world-readable
References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com>
Message-ID: <20130710142111.5380.87073.malone@soybean.canonical.com>

Thanks Xavier.  My patch failed because it narrowed permissions to only
the openstack user, not also the qemu user.

I agree that group permissions should fix this.  But I think it's safer
to do it internally in nova rather than punting to packagers, if we can.
That way we fix it once rather than relying on others to fix it multiple
times.  The challenge is knowing the correct group in a portable way.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1129748

Title:
  image files in _base should not be world-readable

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 ,
  so probably no point making this private.  But I checked the security
  vulnerability box anyway so someone else can decide.

  We create image files in /var/lib/nova/instances/_base with default
  permissions, usually 644.  It would be better to not make the image
  files world-readable, in case they contain private data.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1129748/+subscriptions



From Numero.8 at free.fr  Thu Jul 11 18:56:50 2013
From: Numero.8 at free.fr (Numero 8)
Date: Thu, 11 Jul 2013 18:56:50 -0000
Subject: [Openstack-security] [Bug 1004114] Re: Password logging
References: <20120524190215.26515.18198.malonedeb@gac.canonical.com>
Message-ID: <20130711185650.2774.79785.malone@wampee.canonical.com>

Could any one propose a review of patch set #3 for this bug?

See here: https://review.openstack.org/#/c/33532/

Thank you.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1004114

Title:
  Password logging

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (Keystone):
  Fix Released
Status in Python client library for Keystone:
  In Progress

Bug description:
  When the log level is set to DEBUG, keystoneclient's full-request
  logging mechanism kicks in, exposing plaintext passwords, etc.

  This bug is mostly out of the scope of Horizon, however Horizon can
  also be more secure in this regard. We should make sure that wherever
  we *are* handling sensitive data we use Django's error report
  filtering mechanisms so they don't appear in tracebacks, etc.
  (https://docs.djangoproject.com/en/dev/howto/error-reporting
  /#filtering-error-reports)

  Keystone may also want to look at respecting such annotations in their
  logging mechanism, i.e. if Django were properly annotating these data
  objects, keystoneclient could check for those annotations and properly
  sanitize the log output.

  If not this exact mechanism, then something similar would be wise.

  For the time being, it's also worth documenting in both projects that
  a log level of DEBUG will log passwords in plain text.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions



From 1195431 at bugs.launchpad.net  Fri Jul 12 00:56:05 2013
From: 1195431 at bugs.launchpad.net (OpenStack Hudson)
Date: Fri, 12 Jul 2013 00:56:05 -0000
Subject: [Openstack-security] [Bug 1195431] Re: kombu_ssl_version is a
	cfg.StrOpt but the ssl	socket code requires an Integer value
References: <20130627190934.25966.77326.malonedeb@soybean.canonical.com>
Message-ID: <20130712005605.2987.5660.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/35291
Committed: http://github.com/openstack/oslo-incubator/commit/99b7c354271e2ed0893b3c48c7f2a58a55b59b11
Submitter: Jenkins
Branch:    master

commit 99b7c354271e2ed0893b3c48c7f2a58a55b59b11
Author: Davanum Srinivas <dims at linux.vnet.ibm.com>
Date:   Tue Jul 2 09:08:29 2013 -0400

    Convert kombu SSL version string into integer
    
    When specifying 'kombu_ssl_version' for the RPC driver such as either
    "kombu_ssl_version=3" or "kombu_ssl_version=SSLv3" the relevant
    OpenStack service (nova, cinder, etc) will fail as the underlying
    rpc driver is trying to create an SSL socket which requires an
    integer such as the following built-in SSL integer constants. Added
    a validation step that ensures one can set only the supported ssl
    versions and to convert from the specified string to an integer
    
    Fixes LP# 1195431
    
    Change-Id: I5d188f46a15bc4ba60d573d6b98def60c56cb987


** Changed in: oslo
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1195431

Title:
  kombu_ssl_version is a cfg.StrOpt but the ssl socket code requires an
  Integer value

Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed

Bug description:
  When specifying 'kombu_ssl_version' for the RPC driver such as either
  "kombu_ssl_version=3" or "kombu_ssl_version=SSLv3" the relevant
  OpenStack service (nova, cinder, etc) will fail with the following
  traceback:

  2013-06-27 15:05:30.257 CRITICAL cinder [-] an integer is required
  2013-06-27 15:05:30.257 TRACE cinder Traceback (most recent call last):
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/bin/cinder-scheduler", line 50, in <module>
  2013-06-27 15:05:30.257 TRACE cinder     service.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 624, in wait
  2013-06-27 15:05:30.257 TRACE cinder     _launcher.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 135, in wait
  2013-06-27 15:05:30.257 TRACE cinder     service.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 168, in wait
  2013-06-27 15:05:30.257 TRACE cinder     return self._exit_event.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/event.py", line 116, in wait
  2013-06-27 15:05:30.257 TRACE cinder     return hubs.get_hub().switch()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 187, in switch
  2013-06-27 15:05:30.257 TRACE cinder     return self.greenlet.switch()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 194, in main
  2013-06-27 15:05:30.257 TRACE cinder     result = function(*args, **kwargs)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 96, in run_server
  2013-06-27 15:05:30.257 TRACE cinder     server.start()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 359, in start
  2013-06-27 15:05:30.257 TRACE cinder     self.manager.init_host()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/scheduler/manager.py", line 62, in init_host
  2013-06-27 15:05:30.257 TRACE cinder     self.request_service_capabilities(ctxt)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/scheduler/manager.py", line 141, in request_service_capabilities
  2013-06-27 15:05:30.257 TRACE cinder     volume_rpcapi.VolumeAPI().publish_service_capabilities(context)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/volume/rpcapi.py", line 133, in publish_service_capabilities
  2013-06-27 15:05:30.257 TRACE cinder     version='1.2')
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/proxy.py", line 142, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     rpc.fanout_cast(context, self._get_topic(topic), msg)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/__init__.py", line 179, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     return _get_impl().fanout_cast(CONF, context, topic, msg)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 812, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     rpc_amqp.get_connection_pool(conf, Connection))
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 635, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     with ConnectionContext(conf, connection_pool) as conn:
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 122, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.connection = connection_pool.get()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/pools.py", line 119, in get
  2013-06-27 15:05:30.257 TRACE cinder     created = self.create()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 76, in create
  2013-06-27 15:05:30.257 TRACE cinder     return self.connection_cls(self.conf)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 447, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.reconnect()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 519, in reconnect
  2013-06-27 15:05:30.257 TRACE cinder     self._connect(params)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 495, in _connect
  2013-06-27 15:05:30.257 TRACE cinder     self.connection.connect()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 246, in connect
  2013-06-27 15:05:30.257 TRACE cinder     return self.connection
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 761, in connection
  2013-06-27 15:05:30.257 TRACE cinder     self._connection = self._establish_connection()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 720, in _establish_connection
  2013-06-27 15:05:30.257 TRACE cinder     conn = self.transport.establish_connection()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/transport/pyamqp.py", line 110, in establish_connection
  2013-06-27 15:05:30.257 TRACE cinder     **conninfo.transport_options or {})
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/connection.py", line 136, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.transport = create_transport(host, connect_timeout, ssl)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 252, in create_transport
  2013-06-27 15:05:30.257 TRACE cinder     return SSLTransport(host, connect_timeout, ssl)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 170, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     super(SSLTransport, self).__init__(host, connect_timeout)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 105, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self._setup_transport()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 178, in _setup_transport
  2013-06-27 15:05:30.257 TRACE cinder     self.sslobj = ssl.wrap_socket(self.sock, **self.sslopts)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/green/ssl.py", line 288, in wrap_socket
  2013-06-27 15:05:30.257 TRACE cinder     return GreenSSLSocket(sock, *a, **kw)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/green/ssl.py", line 46, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     super(GreenSSLSocket, self).__init__(sock.fd, *args, **kw)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/ssl.py", line 197, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     ciphers)
  2013-06-27 15:05:30.257 TRACE cinder TypeError: an integer is required

  This is because the underlying rpc driver is trying to create an SSL
  socket which requires an integer such as the following built-in SSL
  integer constants:

  PROTOCOL_SSLv2
  PROTOCOL_SSLv3
  PROTOCOL_SSLv23
  PROTOCOL_TLSv1

To manage notifications about this bug go to:
https://bugs.launchpad.net/oslo/+bug/1195431/+subscriptions



From n.paladi at gmail.com  Fri Jul 12 07:37:28 2013
From: n.paladi at gmail.com (Nicolae Paladi)
Date: Fri, 12 Jul 2013 09:37:28 +0200
Subject: [Openstack-security] data geo-tagging and friends
Message-ID: <CAK0-rpZoot1wcCsDEv9bKBS=c-y2SxVpgsGv9T0E5_hYdvnerg@mail.gmail.com>

Hi,

a side-topic discussed at the IRC
meeting<http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2013-07-11.log>
on
July, 11th was data geo-tagging
(mentioned by malini1); some links were posted:

http://csrc.nist.gov/groups/SMA/forum/documents/april2013presentations/forum_april_11_2013_bartock.pdf

http://csrc.nist.gov/publications/drafts/ir7904/draft_nistir_7904.pdf


while the above are "fluffy" enough, there are some even fluffier research
articles on the
topic:

K. Benson, R. Dowsley, and H. Shacham, “Do you know where your
cloud<http://i20www.iaks.uni-karlsruhe.de/fileadmin/User/Dowsley/pdf/BenDowSha11.pdf>
files are?<http://i20www.iaks.uni-karlsruhe.de/fileadmin/User/Dowsley/pdf/BenDowSha11.pdf>,”
in Proceedings of the 3rd ACM workshop on Cloud computing
security workshop, pp. 73–82, ACM, 2011.

M. Gondree and Z. N. Peterson, “Geolocation of data in the
cloud<http://www.researchgate.net/publication/236626438_Geolocation_of_Data_in_the_Cloud/file/5046351880ab384ea9.pdf>,”
in
Proceedings of the third ACM conference on Data and application security
and privacy, pp. 25–36, ACM, 2013.

Please add more info in case you know more on the topic, I'm somewhat
interested in this.


best regards,
/Nicolae.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130712/3b8d8766/attachment.html>

From 1192971 at bugs.launchpad.net  Thu Jul 11 21:20:23 2013
From: 1192971 at bugs.launchpad.net (OpenStack Hudson)
Date: Thu, 11 Jul 2013 21:20:23 -0000
Subject: [Openstack-security] [Bug 1192971] Re: Command execution cases need
	to be strengthened
References: <20130620133506.19620.30523.malonedeb@gac.canonical.com>
Message-ID: <20130711212025.20375.16410.launchpad@gac.canonical.com>

** Changed in: nova
       Status: Confirmed => In Progress

** Changed in: nova
     Assignee: (unassigned) => Lance Bragstad (ldbragst)

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1192971

Title:
  Command execution cases need to be strengthened

Status in Cinder:
  Confirmed
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Grant Murphy from Red Hat Product Security Team reports the following
  potential vulnerability:

  For the most part OpenStack seems to do command execution safely using
  subprocess.Popen. There are two instances where things become a little
  dubious. The first is when shell=True is used with subprocess. This
  doesn't prevent arguments being supplied that allow for multiple
  commands to be executed. e.g. '; cat /etc/passwd'. The second case is
  where commands are made to an external ssh host.

  See attached file for a lit of potential injections: we should double-
  check them (even if I expect most of them to turn false positive)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1192971/+subscriptions



From haomai at unitedstack.com  Fri Jul 12 02:51:17 2013
From: haomai at unitedstack.com (Haomai Wang)
Date: Fri, 12 Jul 2013 02:51:17 -0000
Subject: [Openstack-security] [Bug 1192971] Re: Command execution cases need
	to be strengthened
References: <20130620133506.19620.30523.malonedeb@gac.canonical.com>
Message-ID: <20130712025120.21612.21197.launchpad@soybean.canonical.com>

** Changed in: cinder
     Assignee: (unassigned) => Haomai Wang (haomai)

** Changed in: cinder
       Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1192971

Title:
  Command execution cases need to be strengthened

Status in Cinder:
  In Progress
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Grant Murphy from Red Hat Product Security Team reports the following
  potential vulnerability:

  For the most part OpenStack seems to do command execution safely using
  subprocess.Popen. There are two instances where things become a little
  dubious. The first is when shell=True is used with subprocess. This
  doesn't prevent arguments being supplied that allow for multiple
  commands to be executed. e.g. '; cat /etc/passwd'. The second case is
  where commands are made to an external ssh host.

  See attached file for a lit of potential injections: we should double-
  check them (even if I expect most of them to turn false positive)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1192971/+subscriptions



From 1175906 at bugs.launchpad.net  Fri Jul 12 14:22:43 2013
From: 1175906 at bugs.launchpad.net (OpenStack Hudson)
Date: Fri, 12 Jul 2013 14:22:43 -0000
Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords
	trigger long checks
References: <20130503065128.15095.65477.malonedeb@gac.canonical.com>
Message-ID: <20130712142245.19689.80584.launchpad@chaenomeles.canonical.com>

** Changed in: keystone
     Assignee: Dolph Mathews (dolph) => Lance Bragstad (ldbragst)

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1175906

Title:
  passlib: long passwords trigger long checks

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  Grant Murphy originally reported:

  * Denial of Service

    The passlib restriction of 4096 for maximum password length is 
    potentially too generous for production environments. On my local machine
    the sha512_crypt algorithm with input of 4096 and 40000
    rounds will potentially introduce a DOS problem:
         feasible length(128) password encrypt:  0.0707409381866  seconds
         feasible length(128) password verify:  0.140727996826  seconds
         excessive length(4096) password encrypt:  1.33277702332  seconds
         excessive length(4096) password verify:  2.66491699219  seconds

  
    I would consider tweaking these values (length or rounds) to reduce 
    the computational overhead here or you're probably going to have a bad time.

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1175906/+subscriptions



From david.lyle at hp.com  Sun Jul 14 05:28:41 2013
From: david.lyle at hp.com (David Lyle)
Date: Sun, 14 Jul 2013 05:28:41 -0000
Subject: [Openstack-security] [Bug 1118441] Re: Horizon does not implement a
	browser session timeout
References: <20130207150751.16050.96632.malonedeb@soybean.canonical.com>
Message-ID: <20130714052843.19384.35736.launchpad@chaenomeles.canonical.com>

** Changed in: horizon
    Milestone: None => havana-2

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1118441

Title:
  Horizon does not implement a browser session timeout

Status in OpenStack Dashboard (Horizon):
  Fix Committed

Bug description:
  Horizon does not terminate user sessions (from a browser) after a
  reasonable period of inactivity. The only timeout is that of
  keystone's token which is often set to very long periods. The only
  session timeout implemented by Horizon is Django's
  SESSION_EXPIRE_AT_BROWSER_CLOSE which closes the session when the
  browser closes.

  Due to the nature of what can be done in Horizon (both now and in the
  future) this could pose significant risk since it enables bystanders
  to make use of unlocked workstations in order to access sensitive data
  and do otherwise unauthorised activities on behalf of what some may
  call a 'careless' end-user.

  Implementing a reasonable inactive session timeout for Horizon would
  mitigate this risk.

  An option to solve this problem could be to include this code:
  https://github.com/subhranath/django-session-idle-timeout

  There is some discussion regarding possible solutions here:
  http://stackoverflow.com/questions/3024153/how-to-expire-session-due-
  to-inactivity-in-django

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1118441/+subscriptions



From gerrit2 at review.openstack.org  Tue Jul 16 13:59:01 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 16 Jul 2013 13:59:01 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50
Message-ID: <E1Uz5mP-0006m6-93@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/30973

Log:
commit d92b06b468cce49962d678d08d521597d5faa25f
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Tue Jul 16 09:56:47 2013 -0400

    Create key manager interface
    
    This interface provides a thin wrapper around an underlying key management
    implementation such as Barbican or a KMIP server. The key manager interface is
    used by the volume encryption code to retrieve keys for volumes.
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50
    SecurityImpact




From thierry.carrez+lp at gmail.com  Wed Jul 17 10:46:32 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 17 Jul 2013 10:46:32 -0000
Subject: [Openstack-security] [Bug 1118441] Re: Horizon does not implement a
	browser session timeout
References: <20130207150751.16050.96632.malonedeb@soybean.canonical.com>
Message-ID: <20130717104636.21717.86952.launchpad@soybean.canonical.com>

** Changed in: horizon
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1118441

Title:
  Horizon does not implement a browser session timeout

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Horizon does not terminate user sessions (from a browser) after a
  reasonable period of inactivity. The only timeout is that of
  keystone's token which is often set to very long periods. The only
  session timeout implemented by Horizon is Django's
  SESSION_EXPIRE_AT_BROWSER_CLOSE which closes the session when the
  browser closes.

  Due to the nature of what can be done in Horizon (both now and in the
  future) this could pose significant risk since it enables bystanders
  to make use of unlocked workstations in order to access sensitive data
  and do otherwise unauthorised activities on behalf of what some may
  call a 'careless' end-user.

  Implementing a reasonable inactive session timeout for Horizon would
  mitigate this risk.

  An option to solve this problem could be to include this code:
  https://github.com/subhranath/django-session-idle-timeout

  There is some discussion regarding possible solutions here:
  http://stackoverflow.com/questions/3024153/how-to-expire-session-due-
  to-inactivity-in-django

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1118441/+subscriptions



From thierry.carrez+lp at gmail.com  Wed Jul 17 12:18:38 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 17 Jul 2013 12:18:38 -0000
Subject: [Openstack-security] [Bug 1074087] Re: XenApi migration driver
	should not use shell=True	with Popen
References: <20121101174933.5279.14962.malonedeb@gac.canonical.com>
Message-ID: <20130717121842.20883.41311.launchpad@gac.canonical.com>

** Changed in: nova
       Status: Fix Committed => Fix Released

** Changed in: nova
    Milestone: None => havana-2

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1074087

Title:
  XenApi migration driver should not use shell=True with Popen

Status in OpenStack Compute (Nova):
  Fix Released

Bug description:
  The XenApi drivers split a string to create an array for
  subprocess.Popen, rather than passing an array directly. This invites
  the potential for command injection / manipulation.

  There is no clearly valid reason to use string splitting here when
  arguments can be passed, as elsewhere, directly into Popen.

  The behavior here is present in current Trunk, Folsom, and Essex.  Per
  Trunk and Folsom, _rsync_vhds calls plugins.utils.subprocess to
  perform the splitting.  In Essex, this behaviorism was present
  directly in migration/transfer_vhd.py, rather than in utils.py.
  Earlier releases have not been evaluated.

  I am not certain if this is directly exploitable. The user field is
  inserted into the generated strings used for command-line execution,
  and it does seem that Keystone allows usernames to contain arbitrary
  tokens/characters such as spaces.  It is not clear to me if the user
  field directly matches that in Keystone, if the user field is
  otherwise validated in the API, etc.  Other fields inserted into the
  command string seem to be internally generated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1074087/+subscriptions



From gerrit2 at review.openstack.org  Wed Jul 17 13:17:43 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 17 Jul 2013 13:17:43 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50
Message-ID: <E1UzRbz-0004mo-Fd@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/30973

Log:
commit 3c365135c1cdd335de4a78bb0fc5307d403cd442
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Tue Jul 16 09:56:47 2013 -0400

    Create key manager interface
    
    This interface provides a thin wrapper around an underlying key management
    implementation such as Barbican or a KMIP server. The key manager interface is
    used by the volume encryption code to retrieve keys for volumes.
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50
    SecurityImpact




From thierry.carrez+lp at gmail.com  Wed Jul 17 12:40:45 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 17 Jul 2013 12:40:45 -0000
Subject: [Openstack-security] [Bug 1195431] Re: kombu_ssl_version is a
	cfg.StrOpt but the ssl	socket code requires an Integer value
References: <20130627190934.25966.77326.malonedeb@soybean.canonical.com>
Message-ID: <20130717124048.21647.7770.launchpad@soybean.canonical.com>

** Changed in: oslo
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1195431

Title:
  kombu_ssl_version is a cfg.StrOpt but the ssl socket code requires an
  Integer value

Status in Oslo - a Library of Common OpenStack Code:
  Fix Released

Bug description:
  When specifying 'kombu_ssl_version' for the RPC driver such as either
  "kombu_ssl_version=3" or "kombu_ssl_version=SSLv3" the relevant
  OpenStack service (nova, cinder, etc) will fail with the following
  traceback:

  2013-06-27 15:05:30.257 CRITICAL cinder [-] an integer is required
  2013-06-27 15:05:30.257 TRACE cinder Traceback (most recent call last):
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/bin/cinder-scheduler", line 50, in <module>
  2013-06-27 15:05:30.257 TRACE cinder     service.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 624, in wait
  2013-06-27 15:05:30.257 TRACE cinder     _launcher.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 135, in wait
  2013-06-27 15:05:30.257 TRACE cinder     service.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 168, in wait
  2013-06-27 15:05:30.257 TRACE cinder     return self._exit_event.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/event.py", line 116, in wait
  2013-06-27 15:05:30.257 TRACE cinder     return hubs.get_hub().switch()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 187, in switch
  2013-06-27 15:05:30.257 TRACE cinder     return self.greenlet.switch()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 194, in main
  2013-06-27 15:05:30.257 TRACE cinder     result = function(*args, **kwargs)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 96, in run_server
  2013-06-27 15:05:30.257 TRACE cinder     server.start()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 359, in start
  2013-06-27 15:05:30.257 TRACE cinder     self.manager.init_host()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/scheduler/manager.py", line 62, in init_host
  2013-06-27 15:05:30.257 TRACE cinder     self.request_service_capabilities(ctxt)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/scheduler/manager.py", line 141, in request_service_capabilities
  2013-06-27 15:05:30.257 TRACE cinder     volume_rpcapi.VolumeAPI().publish_service_capabilities(context)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/volume/rpcapi.py", line 133, in publish_service_capabilities
  2013-06-27 15:05:30.257 TRACE cinder     version='1.2')
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/proxy.py", line 142, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     rpc.fanout_cast(context, self._get_topic(topic), msg)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/__init__.py", line 179, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     return _get_impl().fanout_cast(CONF, context, topic, msg)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 812, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     rpc_amqp.get_connection_pool(conf, Connection))
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 635, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     with ConnectionContext(conf, connection_pool) as conn:
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 122, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.connection = connection_pool.get()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/pools.py", line 119, in get
  2013-06-27 15:05:30.257 TRACE cinder     created = self.create()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 76, in create
  2013-06-27 15:05:30.257 TRACE cinder     return self.connection_cls(self.conf)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 447, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.reconnect()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 519, in reconnect
  2013-06-27 15:05:30.257 TRACE cinder     self._connect(params)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 495, in _connect
  2013-06-27 15:05:30.257 TRACE cinder     self.connection.connect()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 246, in connect
  2013-06-27 15:05:30.257 TRACE cinder     return self.connection
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 761, in connection
  2013-06-27 15:05:30.257 TRACE cinder     self._connection = self._establish_connection()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 720, in _establish_connection
  2013-06-27 15:05:30.257 TRACE cinder     conn = self.transport.establish_connection()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/transport/pyamqp.py", line 110, in establish_connection
  2013-06-27 15:05:30.257 TRACE cinder     **conninfo.transport_options or {})
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/connection.py", line 136, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.transport = create_transport(host, connect_timeout, ssl)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 252, in create_transport
  2013-06-27 15:05:30.257 TRACE cinder     return SSLTransport(host, connect_timeout, ssl)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 170, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     super(SSLTransport, self).__init__(host, connect_timeout)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 105, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self._setup_transport()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 178, in _setup_transport
  2013-06-27 15:05:30.257 TRACE cinder     self.sslobj = ssl.wrap_socket(self.sock, **self.sslopts)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/green/ssl.py", line 288, in wrap_socket
  2013-06-27 15:05:30.257 TRACE cinder     return GreenSSLSocket(sock, *a, **kw)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/green/ssl.py", line 46, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     super(GreenSSLSocket, self).__init__(sock.fd, *args, **kw)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/ssl.py", line 197, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     ciphers)
  2013-06-27 15:05:30.257 TRACE cinder TypeError: an integer is required

  This is because the underlying rpc driver is trying to create an SSL
  socket which requires an integer such as the following built-in SSL
  integer constants:

  PROTOCOL_SSLv2
  PROTOCOL_SSLv3
  PROTOCOL_SSLv23
  PROTOCOL_TLSv1

To manage notifications about this bug go to:
https://bugs.launchpad.net/oslo/+bug/1195431/+subscriptions



From 1192971 at bugs.launchpad.net  Wed Jul 17 13:39:55 2013
From: 1192971 at bugs.launchpad.net (OpenStack Hudson)
Date: Wed, 17 Jul 2013 13:39:55 -0000
Subject: [Openstack-security] [Bug 1192971] Fix proposed to cinder (master)
References: <20130620133506.19620.30523.malonedeb@gac.canonical.com>
Message-ID: <20130717133955.21493.71833.malone@soybean.canonical.com>

Fix proposed to branch: master
Review: https://review.openstack.org/37469

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1192971

Title:
  Command execution cases need to be strengthened

Status in Cinder:
  In Progress
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Grant Murphy from Red Hat Product Security Team reports the following
  potential vulnerability:

  For the most part OpenStack seems to do command execution safely using
  subprocess.Popen. There are two instances where things become a little
  dubious. The first is when shell=True is used with subprocess. This
  doesn't prevent arguments being supplied that allow for multiple
  commands to be executed. e.g. '; cat /etc/passwd'. The second case is
  where commands are made to an external ssh host.

  See attached file for a lit of potential injections: we should double-
  check them (even if I expect most of them to turn false positive)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1192971/+subscriptions



From 1129748 at bugs.launchpad.net  Wed Jul 17 12:14:10 2013
From: 1129748 at bugs.launchpad.net (Russell Bryant)
Date: Wed, 17 Jul 2013 12:14:10 -0000
Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should
	not be world-readable
References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com>
Message-ID: <20130717121413.19351.47061.launchpad@chaenomeles.canonical.com>

** Changed in: nova
    Milestone: havana-2 => havana-3

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1129748

Title:
  image files in _base should not be world-readable

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 ,
  so probably no point making this private.  But I checked the security
  vulnerability box anyway so someone else can decide.

  We create image files in /var/lib/nova/instances/_base with default
  permissions, usually 644.  It would be better to not make the image
  files world-readable, in case they contain private data.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1129748/+subscriptions



From 1004114 at bugs.launchpad.net  Wed Jul 17 16:40:55 2013
From: 1004114 at bugs.launchpad.net (Matthew Thode)
Date: Wed, 17 Jul 2013 16:40:55 -0000
Subject: [Openstack-security] [Bug 1004114] Re: Password logging
References: <20120524190215.26515.18198.malonedeb@gac.canonical.com>
Message-ID: <20130717164056.20651.36014.malone@gac.canonical.com>

anyone able to review this patchset?
https://review.openstack.org/#/c/33532/

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1004114

Title:
  Password logging

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (Keystone):
  Fix Released
Status in Python client library for Keystone:
  In Progress

Bug description:
  When the log level is set to DEBUG, keystoneclient's full-request
  logging mechanism kicks in, exposing plaintext passwords, etc.

  This bug is mostly out of the scope of Horizon, however Horizon can
  also be more secure in this regard. We should make sure that wherever
  we *are* handling sensitive data we use Django's error report
  filtering mechanisms so they don't appear in tracebacks, etc.
  (https://docs.djangoproject.com/en/dev/howto/error-reporting
  /#filtering-error-reports)

  Keystone may also want to look at respecting such annotations in their
  logging mechanism, i.e. if Django were properly annotating these data
  objects, keystoneclient could check for those annotations and properly
  sanitize the log output.

  If not this exact mechanism, then something similar would be wise.

  For the time being, it's also worth documenting in both projects that
  a log level of DEBUG will log passwords in plain text.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions



From 1074087 at bugs.launchpad.net  Wed Jul 17 16:49:29 2013
From: 1074087 at bugs.launchpad.net (Matthew Thode)
Date: Wed, 17 Jul 2013 16:49:29 -0000
Subject: [Openstack-security] [Bug 1074087] Re: XenApi migration driver
	should not use shell=True	with Popen
References: <20121101174933.5279.14962.malonedeb@gac.canonical.com>
Message-ID: <20130717164929.21890.47134.malone@soybean.canonical.com>

Is this fix going to be backported to folsom or grizzly? (does it need
to be backported)?

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1074087

Title:
  XenApi migration driver should not use shell=True with Popen

Status in OpenStack Compute (Nova):
  Fix Released

Bug description:
  The XenApi drivers split a string to create an array for
  subprocess.Popen, rather than passing an array directly. This invites
  the potential for command injection / manipulation.

  There is no clearly valid reason to use string splitting here when
  arguments can be passed, as elsewhere, directly into Popen.

  The behavior here is present in current Trunk, Folsom, and Essex.  Per
  Trunk and Folsom, _rsync_vhds calls plugins.utils.subprocess to
  perform the splitting.  In Essex, this behaviorism was present
  directly in migration/transfer_vhd.py, rather than in utils.py.
  Earlier releases have not been evaluated.

  I am not certain if this is directly exploitable. The user field is
  inserted into the generated strings used for command-line execution,
  and it does seem that Keystone allows usernames to contain arbitrary
  tokens/characters such as spaces.  It is not clear to me if the user
  field directly matches that in Keystone, if the user field is
  otherwise validated in the API, etc.  Other fields inserted into the
  command string seem to be internally generated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1074087/+subscriptions



From gerrit2 at review.openstack.org  Wed Jul 17 19:15:42 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 17 Jul 2013 19:15:42 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50
Message-ID: <E1UzXCQ-0006BB-Eb@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/30973

Log:
commit 4e8185e41dee9e39344af92a13aef5a26eb0ed81
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Tue Jul 16 09:56:47 2013 -0400

    Create key manager interface
    
    This interface provides a thin wrapper around an underlying key management
    implementation such as Barbican or a KMIP server. The key manager interface is
    used by the volume encryption code to retrieve keys for volumes.
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50
    SecurityImpact




From gerrit2 at review.openstack.org  Wed Jul 17 21:18:27 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 17 Jul 2013 21:18:27 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50
Message-ID: <E1UzZ7D-0001S9-38@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/30973

Log:
commit fc8cb355db01032d808608d991ca04fa5f008286
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Tue Jul 16 09:56:47 2013 -0400

    Create key manager interface
    
    This interface provides a thin wrapper around an underlying key management
    implementation such as Barbican or a KMIP server. The key manager interface is
    used by the volume encryption code to retrieve keys for volumes.
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50
    SecurityImpact




From clint at fewbar.com  Mon Jul 15 18:08:38 2013
From: clint at fewbar.com (Clint Byrum)
Date: Mon, 15 Jul 2013 18:08:38 -0000
Subject: [Openstack-security] [Bug 1201534] [NEW] heat.common.urlfetch does
	not validate server SSL	certificates
References: <20130715180838.2851.94826.malonedeb@wampee.canonical.com>
Message-ID: <20130715180838.2851.94826.malonedeb@wampee.canonical.com>

Public bug reported:

urllib2 is not considered "safe" for SSL communications. It does nothing
to validate the server SSL certificate.

We should migrate to requests, which has become common in OpenStack.

** Affects: heat
     Importance: High
         Status: Triaged


** Tags: security

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1201534

Title:
  heat.common.urlfetch does not validate server SSL certificates

Status in Orchestration API (Heat):
  Triaged

Bug description:
  urllib2 is not considered "safe" for SSL communications. It does
  nothing to validate the server SSL certificate.

  We should migrate to requests, which has become common in OpenStack.

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1201534/+subscriptions



From 1129748 at bugs.launchpad.net  Thu Jul 18 10:16:26 2013
From: 1129748 at bugs.launchpad.net (OpenStack Hudson)
Date: Thu, 18 Jul 2013 10:16:26 -0000
Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should
	not be world-readable
References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com>
Message-ID: <20130718101628.20618.42591.launchpad@gac.canonical.com>

** Changed in: nova
     Assignee: David Ripton (dripton) => Xavier Queralt (xqueralt)

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1129748

Title:
  image files in _base should not be world-readable

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 ,
  so probably no point making this private.  But I checked the security
  vulnerability box anyway so someone else can decide.

  We create image files in /var/lib/nova/instances/_base with default
  permissions, usually 644.  It would be better to not make the image
  files world-readable, in case they contain private data.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1129748/+subscriptions



From 1192971 at bugs.launchpad.net  Thu Jul 18 15:04:32 2013
From: 1192971 at bugs.launchpad.net (OpenStack Hudson)
Date: Thu, 18 Jul 2013 15:04:32 -0000
Subject: [Openstack-security] [Bug 1192971] Re: Command execution cases need
	to be strengthened
References: <20130620133506.19620.30523.malonedeb@gac.canonical.com>
Message-ID: <20130718150432.19417.40440.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/37469
Committed: http://github.com/openstack/cinder/commit/6be79a8e3b4607adbbe6a26ee565156cd0fb36b0
Submitter: Jenkins
Branch:    master

commit 6be79a8e3b4607adbbe6a26ee565156cd0fb36b0
Author: Haomai Wang <haomai at unitedstack.com>
Date:   Wed Jul 17 21:36:55 2013 +0800

    Tidy up the SSH call to avoid injection attacks in storwize_svc
    
    Let the command and arguments form up a list and avoid the extra arguments
    attackers inserted to the command string
    
    fix bug 1192971
    
    Change-Id: I72bb7ef137223381c9daa613e61f1fde4c3bc8ae


** Changed in: cinder
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1192971

Title:
  Command execution cases need to be strengthened

Status in Cinder:
  Fix Committed
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Grant Murphy from Red Hat Product Security Team reports the following
  potential vulnerability:

  For the most part OpenStack seems to do command execution safely using
  subprocess.Popen. There are two instances where things become a little
  dubious. The first is when shell=True is used with subprocess. This
  doesn't prevent arguments being supplied that allow for multiple
  commands to be executed. e.g. '; cat /etc/passwd'. The second case is
  where commands are made to an external ssh host.

  See attached file for a lit of potential injections: we should double-
  check them (even if I expect most of them to turn false positive)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1192971/+subscriptions



From robert.clark at hp.com  Tue Jul 23 14:34:39 2013
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 23 Jul 2013 14:34:39 +0000
Subject: [Openstack-security] Security Presentations - Talks
Message-ID: <CE14530E.1D0A4%robert.clark@hp.com>

Hi Guys,

I'm planning on presenting on the state of security for the virtualization stack. I've got a lot I want to say here and the locking-down / mitigation side of this will borrow from the hypervisor guidance in the security guide – as I'm not the primary author on that section does anyone mind me referencing it?

Cheers
-Rob



From 1201534 at bugs.launchpad.net  Wed Jul 24 02:10:04 2013
From: 1201534 at bugs.launchpad.net (OpenStack Hudson)
Date: Wed, 24 Jul 2013 02:10:04 -0000
Subject: [Openstack-security] [Bug 1201534] Re: heat.common.urlfetch does
	not validate server SSL	certificates
References: <20130715180838.2851.94826.malonedeb@wampee.canonical.com>
Message-ID: <20130724021004.7547.82827.malone@chaenomeles.canonical.com>

Fix proposed to branch: master
Review: https://review.openstack.org/38403

** Changed in: heat
       Status: Triaged => In Progress

** Changed in: heat
     Assignee: (unassigned) => Davanum Srinivas (DIMS) (dims-v)

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1201534

Title:
  heat.common.urlfetch does not validate server SSL certificates

Status in Orchestration API (Heat):
  In Progress

Bug description:
  urllib2 is not considered "safe" for SSL communications. It does
  nothing to validate the server SSL certificate.

  We should migrate to requests, which has become common in OpenStack.

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1201534/+subscriptions



From 1201534 at bugs.launchpad.net  Thu Jul 25 00:59:18 2013
From: 1201534 at bugs.launchpad.net (OpenStack Hudson)
Date: Thu, 25 Jul 2013 00:59:18 -0000
Subject: [Openstack-security] [Bug 1201534] Re: heat.common.urlfetch does
	not validate server SSL	certificates
References: <20130715180838.2851.94826.malonedeb@wampee.canonical.com>
Message-ID: <20130725005918.24405.52429.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/38403
Committed: http://github.com/openstack/heat/commit/50e177e3c9c207ff832aac6adcafcf81a181a145
Submitter: Jenkins
Branch:    master

commit 50e177e3c9c207ff832aac6adcafcf81a181a145
Author: Davanum Srinivas <dims at linux.vnet.ibm.com>
Date:   Tue Jul 23 22:08:20 2013 -0400

    Replace urllib2 with requests in urlfetch module
    
    simple replacement of urllib2.urlopen with requests.get
    
    Fixes LP# 1201534
    
    Change-Id: Ia0a2ed3b092e22246339a42f432086dd05f788fa


** Changed in: heat
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1201534

Title:
  heat.common.urlfetch does not validate server SSL certificates

Status in Orchestration API (Heat):
  Fix Committed

Bug description:
  urllib2 is not considered "safe" for SSL communications. It does
  nothing to validate the server SSL certificate.

  We should migrate to requests, which has become common in OpenStack.

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1201534/+subscriptions



From euan.harris at citrix.com  Thu Jul 25 09:04:27 2013
From: euan.harris at citrix.com (Euan Harris)
Date: Thu, 25 Jul 2013 09:04:27 -0000
Subject: [Openstack-security] [Bug 1074087] Re: XenApi migration driver
	should not use shell=True	with Popen
References: <20121101174933.5279.14962.malonedeb@gac.canonical.com>
Message-ID: <20130725090427.17315.51377.malone@soybean.canonical.com>

The analysis in comment #2 suggests that, since the calls to Popen and
split don't take any user input, this bug doesn't allow an attack from
the outside.   Therefore it isn't necessary to backport it.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1074087

Title:
  XenApi migration driver should not use shell=True with Popen

Status in OpenStack Compute (Nova):
  Fix Released

Bug description:
  The XenApi drivers split a string to create an array for
  subprocess.Popen, rather than passing an array directly. This invites
  the potential for command injection / manipulation.

  There is no clearly valid reason to use string splitting here when
  arguments can be passed, as elsewhere, directly into Popen.

  The behavior here is present in current Trunk, Folsom, and Essex.  Per
  Trunk and Folsom, _rsync_vhds calls plugins.utils.subprocess to
  perform the splitting.  In Essex, this behaviorism was present
  directly in migration/transfer_vhd.py, rather than in utils.py.
  Earlier releases have not been evaluated.

  I am not certain if this is directly exploitable. The user field is
  inserted into the generated strings used for command-line execution,
  and it does seem that Keystone allows usernames to contain arbitrary
  tokens/characters such as spaces.  It is not clear to me if the user
  field directly matches that in Keystone, if the user field is
  otherwise validated in the API, etc.  Other fields inserted into the
  command string seem to be internally generated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1074087/+subscriptions



From gerrit2 at review.openstack.org  Fri Jul 26 15:49:06 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 26 Jul 2013 15:49:06 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change If5ac48c5c889034c7b0ba24d977e8f4a14137a12
Message-ID: <E1V2kGQ-0007Gf-Cl@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/36078

Log:
commit edf8f65f319a41f0db997dcd8a89e9b52d67af8a
Author: Lance Bragstad <ldbragst at us.ibm.com>
Date:   Mon Jul 1 19:49:21 2013 +0000

    Address security concerns in PowerVM Driver
    
    Add two methods to common.py that will help build and sanitize commands
    being sent to the remote VIOS system to prevent shell injection.
    
    fixes bug 1192971
    
    [SecurityImpact]
    
    Change-Id: If5ac48c5c889034c7b0ba24d977e8f4a14137a12




From 1188189 at bugs.launchpad.net  Thu Jul 25 15:18:01 2013
From: 1188189 at bugs.launchpad.net (Robert Clark)
Date: Thu, 25 Jul 2013 15:18:01 -0000
Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL'
	communication fails to check	certificates (use of HTTPSConnection)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20130725151801.7495.64702.malone@chaenomeles.canonical.com>

Some SSL-Enabled connections fail to perform basic certificate checks
----

### Summary ###
In many places OpenStack components use Python 2.x HTTPSConnection to establish an SSL connection between endpoints. This does not provide many of the assurances one would expect when using SSL and leaves connections open to potential man-in-the-middle attacks

### Affected Services / Software ###
keystone/middleware/s3_token.py
keystone/middleware/ec2_token.py
keystone/common/bufferedhttp.py
vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py
<<<<OTHERS NEED TO BE ADDED HERE>>>>>

### Discussion ###
A secure SSL session relies on validation of a X.509 certificate. Basic checks include: 
* Is the certificate signed by a CA I recognize
* Has the CA revoked this certificate
* Does the common name on the certificate match the server I'm trying to reach

The HTTPSConnection class is used in a large number of locations and
fails to check that certificates are signed by a valid authority.
Without that check in place, the following checks (some highlighted
above) are largely invalid.

The result is that an attacker who has access to the network traffic
between two endpoints relying on HTTPSConnection can trivially create a
certificate that will be accepted by HTTPSConnection as valid - allowing
the attacker to intercept, read and modify traffic that should be
encrypted by SSL.

### Recommended Actions ###
<<<< MORE INVESTIGATION REQUIRED here on short-long term options >>>>

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1188189
OpenStack Security ML : openstack-security at lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1188189

Title:
  Some server-side 'SSL' communication fails to check certificates (use
  of HTTPSConnection)

Status in Cinder:
  Confirmed
Status in OpenStack Identity (Keystone):
  Confirmed
Status in OpenStack Neutron (virtual network service):
  Confirmed
Status in OpenStack Compute (Nova):
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  In Progress
Status in Python client library for Keystone:
  Confirmed
Status in OpenStack Object Storage (Swift):
  Invalid

Bug description:
  Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection
  objects. In Python 2.x those do not perform CA checks so client
  connections are vulnerable to MiM attacks.

  """
  The following files use httplib.HTTPSConnection :
  keystone/middleware/s3_token.py
  keystone/middleware/ec2_token.py
  keystone/common/bufferedhttp.py
  vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py

  AFAICT HTTPSConnection does not validate server certificates and
  should be avoided. This is fixed in Python 3, however in 2.X no
  validation occurs. I suspect this is also applicable to most OpenStack
  modules that make HTTPS client calls.

  Similar problems were found in ovirt:
  https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533)

  With solutions for ovirt:
  http://gerrit.ovirt.org/#/c/7209/
  http://gerrit.ovirt.org/#/c/7249/
  """

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions



From xiaoxi.chen at intel.com  Sun Jul 28 05:17:36 2013
From: xiaoxi.chen at intel.com (xiaoxi_chen)
Date: Sun, 28 Jul 2013 05:17:36 -0000
Subject: [Openstack-security] [Bug 1192971] Re: Command execution cases need
	to be strengthened
References: <20130620133506.19620.30523.malonedeb@gac.canonical.com>
Message-ID: <20130728051739.17198.45235.launchpad@soybean.canonical.com>

** Changed in: cinder
       Status: Fix Committed => In Progress

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1192971

Title:
  Command execution cases need to be strengthened

Status in Cinder:
  In Progress
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Grant Murphy from Red Hat Product Security Team reports the following
  potential vulnerability:

  For the most part OpenStack seems to do command execution safely using
  subprocess.Popen. There are two instances where things become a little
  dubious. The first is when shell=True is used with subprocess. This
  doesn't prevent arguments being supplied that allow for multiple
  commands to be executed. e.g. '; cat /etc/passwd'. The second case is
  where commands are made to an external ssh host.

  See attached file for a lit of potential injections: we should double-
  check them (even if I expect most of them to turn false positive)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1192971/+subscriptions



From gerrit2 at review.openstack.org  Mon Jul 29 17:35:14 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 29 Jul 2013 17:35:14 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change If5ac48c5c889034c7b0ba24d977e8f4a14137a12
Message-ID: <E1V3rLm-0001CA-KK@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/36078

Log:
commit 1c7c0e810223ff5c67b8a424cf99656fde7ed1b0
Author: Lance Bragstad <ldbragst at us.ibm.com>
Date:   Mon Jul 1 19:49:21 2013 +0000

    Address security concerns in PowerVM Driver
    
    Add two methods to common.py that will help build and check commands
    being sent to the remote VIOS system to prevent shell injection.
    
    fixes bug 1192971
    
    [SecurityImpact]
    
    Change-Id: If5ac48c5c889034c7b0ba24d977e8f4a14137a12




From brian.schott at nimbisservices.com  Mon Jul 29 19:24:57 2013
From: brian.schott at nimbisservices.com (Brian Schott)
Date: Mon, 29 Jul 2013 15:24:57 -0400
Subject: [Openstack-security] develop a common State of OpenStack Security
	briefing
Message-ID: <B543C3BE-B5CA-4AB4-9369-74FEA6E1BFAB@nimbisservices.com>

I was thinking that it would be great if we could collectively have a common "State of OpenStack Security" that Stackers could give at local OpenStack MeetUps or other venues.  This topic comes up all of the time and a good executive overview briefing would raise the awareness of what OpenStack is doing in this space.  

Is there interest in OSSG in pulling together such a briefing?  
Brian

-------------------------------------------------
Brian Schott, CTO
Nimbis Services, Inc.
brian.schott at nimbisservices.com
ph: 443-274-6064  fx: 443-274-6060



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130729/2ddce074/attachment.html>

From prometheanfire at gentoo.org  Mon Jul 29 20:56:02 2013
From: prometheanfire at gentoo.org (Matthew Thode)
Date: Mon, 29 Jul 2013 15:56:02 -0500
Subject: [Openstack-security] develop a common State of OpenStack
 Security briefing
In-Reply-To: <B543C3BE-B5CA-4AB4-9369-74FEA6E1BFAB@nimbisservices.com>
References: <B543C3BE-B5CA-4AB4-9369-74FEA6E1BFAB@nimbisservices.com>
Message-ID: <51F6D6E2.4040608@gentoo.org>

On 07/29/2013 02:24 PM, Brian Schott wrote:
> I was thinking that it would be great if we could collectively have a common "State of OpenStack Security" that Stackers could give at local OpenStack MeetUps or other venues.  This topic comes up all of the time and a good executive overview briefing would raise the awareness of what OpenStack is doing in this space.  
> 
> Is there interest in OSSG in pulling together such a briefing?  
> Brian
> 
> -------------------------------------------------
> Brian Schott, CTO
> Nimbis Services, Inc.
> brian.schott at nimbisservices.com
> ph: 443-274-6064  fx: 443-274-6060
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 
Yes :D

-- 
-- Matthew Thode (prometheanfire)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130729/e2e88d96/attachment.sig>

From bdpayne at acm.org  Mon Jul 29 21:56:48 2013
From: bdpayne at acm.org (Bryan D. Payne)
Date: Mon, 29 Jul 2013 14:56:48 -0700
Subject: [Openstack-security] develop a common State of OpenStack
	Security briefing
In-Reply-To: <B543C3BE-B5CA-4AB4-9369-74FEA6E1BFAB@nimbisservices.com>
References: <B543C3BE-B5CA-4AB4-9369-74FEA6E1BFAB@nimbisservices.com>
Message-ID: <CAFpPvXCesBDfKbe9nXRzcie2bxN-CXqOzAEN-xYBJzs8RtVU8w@mail.gmail.com>

This sounds very valuable.  What kinds of information would you guys like
to see in this?

Also, I'm thinking the slides could be setup in a way that suits either 30
min or 60 min presentation lengths.  Does that seem reasonable?

-bryan


On Mon, Jul 29, 2013 at 12:24 PM, Brian Schott <
brian.schott at nimbisservices.com> wrote:

> I was thinking that it would be great if we could collectively have a
> common "State of OpenStack Security" that Stackers could give at local
> OpenStack MeetUps or other venues.  This topic comes up all of the time and
> a good executive overview briefing would raise the awareness of what
> OpenStack is doing in this space.
>
> Is there interest in OSSG in pulling together such a briefing?
> Brian
>
>  -------------------------------------------------
> Brian Schott, CTO
> Nimbis Services, Inc.
> brian.schott at nimbisservices.com
> ph: 443-274-6064  fx: 443-274-6060
>
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130729/7f5c67f5/attachment.html>

From n.paladi at gmail.com  Tue Jul 30 06:24:49 2013
From: n.paladi at gmail.com (Nicolae Paladi)
Date: Tue, 30 Jul 2013 08:24:49 +0200
Subject: [Openstack-security] develop a common State of OpenStack
	Security briefing
In-Reply-To: <CAFpPvXCesBDfKbe9nXRzcie2bxN-CXqOzAEN-xYBJzs8RtVU8w@mail.gmail.com>
References: <B543C3BE-B5CA-4AB4-9369-74FEA6E1BFAB@nimbisservices.com>
 <CAFpPvXCesBDfKbe9nXRzcie2bxN-CXqOzAEN-xYBJzs8RtVU8w@mail.gmail.com>
Message-ID: <CAK0-rpYZmqgUUZ473e8vPms2Z0zyvYiasNm7UqLT5+ayW-ywTg@mail.gmail.com>

Great initiative, I'd be glad to "test drive" such a presentation at our
next OpenStack meetup in September;

Just my 2 cents: would be good to have a slide or two on the state of VPN
support in Neutron, as well as what the capabilities of security groups are

/nicolae


On 29 July 2013 23:56, Bryan D. Payne <bdpayne at acm.org> wrote:

> This sounds very valuable.  What kinds of information would you guys like
> to see in this?
>
> Also, I'm thinking the slides could be setup in a way that suits either 30
> min or 60 min presentation lengths.  Does that seem reasonable?
>
> -bryan
>
>
> On Mon, Jul 29, 2013 at 12:24 PM, Brian Schott <
> brian.schott at nimbisservices.com> wrote:
>
>> I was thinking that it would be great if we could collectively have a
>> common "State of OpenStack Security" that Stackers could give at local
>> OpenStack MeetUps or other venues.  This topic comes up all of the time and
>> a good executive overview briefing would raise the awareness of what
>> OpenStack is doing in this space.
>>
>> Is there interest in OSSG in pulling together such a briefing?
>> Brian
>>
>>  -------------------------------------------------
>> Brian Schott, CTO
>> Nimbis Services, Inc.
>> brian.schott at nimbisservices.com
>> ph: 443-274-6064  fx: 443-274-6060
>>
>>
>>
>>
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130730/6e5873aa/attachment.html>

From robert.clark at hp.com  Tue Jul 30 12:00:23 2013
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 30 Jul 2013 12:00:23 +0000
Subject: [Openstack-security] develop a common State of
	OpenStack	Security briefing
In-Reply-To: <CAK0-rpYZmqgUUZ473e8vPms2Z0zyvYiasNm7UqLT5+ayW-ywTg@mail.gmail.com>
References: <B543C3BE-B5CA-4AB4-9369-74FEA6E1BFAB@nimbisservices.com>
 <CAFpPvXCesBDfKbe9nXRzcie2bxN-CXqOzAEN-xYBJzs8RtVU8w@mail.gmail.com>
 <CAK0-rpYZmqgUUZ473e8vPms2Z0zyvYiasNm7UqLT5+ayW-ywTg@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A10EC8F012@G4W3202.americas.hpqcorp.net>

I'd certainly be happy to throw some time into this.

 

Things I'd expect to see in the deck:

.        Holistic overview, general security posture

.        Service overview, perhaps restricted to core IaaS services or
wider

o   Covers secure configuration

o   Especially new options, improvements

o   Security Bugs

o   Design issues

.        Review of recent security issues and OSSNs

.        ?

 

From: Nicolae Paladi [mailto:n.paladi at gmail.com] 
Sent: 30 July 2013 07:25
To: Bryan D. Payne
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] develop a common State of OpenStack
Security briefing

 

Great initiative, I'd be glad to "test drive" such a presentation at our
next OpenStack meetup in September;

 

Just my 2 cents: would be good to have a slide or two on the state of
VPN support in Neutron, as well as what the capabilities of security
groups are

 

/nicolae

 

On 29 July 2013 23:56, Bryan D. Payne <bdpayne at acm.org> wrote:

This sounds very valuable.  What kinds of information would you guys
like to see in this?

 

Also, I'm thinking the slides could be setup in a way that suits either
30 min or 60 min presentation lengths.  Does that seem reasonable?

 

-bryan

 

On Mon, Jul 29, 2013 at 12:24 PM, Brian Schott
<brian.schott at nimbisservices.com> wrote:

I was thinking that it would be great if we could collectively have a
common "State of OpenStack Security" that Stackers could give at local
OpenStack MeetUps or other venues.  This topic comes up all of the time
and a good executive overview briefing would raise the awareness of what
OpenStack is doing in this space.  

 

Is there interest in OSSG in pulling together such a briefing?  

Brian

 

-------------------------------------------------

Brian Schott, CTO

Nimbis Services, Inc.

brian.schott at nimbisservices.com

ph: 443-274-6064  fx: 443-274-6060

 

 

 


_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

 


_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130730/b9c227f9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130730/b9c227f9/attachment.bin>

From gerrit2 at review.openstack.org  Tue Jul 30 14:45:41 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 30 Jul 2013 14:45:41 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I164290e761a9922919a70f22f99af70dac213b61
Message-ID: <E1V4BBF-0005l2-7y@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/30974

Log:
commit c142bbe2dbc39eb174579873e33bbc5793637f1d
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Tue Jul 30 10:44:58 2013 -0400

    Add encryption metadata to volume table
    
    This modification adds an encryption key UUID field to the volume
    table, which is sufficient to make Cinder "aware" of encrypted volumes
    as designated by predefined volume types. Integration with a key
    manager is necessary to obtain an actual encryption key UUID (the
    current implementation generates a random UUID when an encrypted
    volumes is created). Cinder should *not* presume that it necessarily
    will have access to the key itself -- this decision depends upon the
    design, implementation, and policy for encrypted volumes. The key's
    UUID is stored in Cinder because it is metadata about the volume.
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I164290e761a9922919a70f22f99af70dac213b61
    SecurityImpact




From bdpayne at acm.org  Tue Jul 30 16:31:41 2013
From: bdpayne at acm.org (Bryan D. Payne)
Date: Tue, 30 Jul 2013 09:31:41 -0700
Subject: [Openstack-security] develop a common State of OpenStack
	Security briefing
In-Reply-To: <A0C170085C37664D93EE1604364858A10EC8F012@G4W3202.americas.hpqcorp.net>
References: <B543C3BE-B5CA-4AB4-9369-74FEA6E1BFAB@nimbisservices.com>
 <CAFpPvXCesBDfKbe9nXRzcie2bxN-CXqOzAEN-xYBJzs8RtVU8w@mail.gmail.com>
 <CAK0-rpYZmqgUUZ473e8vPms2Z0zyvYiasNm7UqLT5+ayW-ywTg@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A10EC8F012@G4W3202.americas.hpqcorp.net>
Message-ID: <CAFpPvXB8VuRdt8XkfYRPq3oa=GvKdgEhQfzgpqy8wKedKo-7CQ@mail.gmail.com>

I think that it's useful to talk about the "glue components" (e.g., the
message queue, database, etc) and current thinking on best practices there.
 Also, on best practices for deployment and keeping everything up to date.
 Finally, I think it's important to highlight both the good things that we
have today, but also the gaps / areas where improvement is needed.

-bryan


On Tue, Jul 30, 2013 at 5:00 AM, Clark, Robert Graham
<robert.clark at hp.com>wrote:

> I’d certainly be happy to throw some time into this.****
>
> ** **
>
> Things I’d expect to see in the deck:****
>
> **·        **Holistic overview, general security posture****
>
> **·        **Service overview, perhaps restricted to core IaaS services
> or wider****
>
> **o   **Covers secure configuration****
>
> **o   **Especially new options, improvements****
>
> **o   **Security Bugs****
>
> **o   **Design issues****
>
> **·        **Review of recent security issues and OSSNs****
>
> **·        **?****
>
> ** **
>
> *From:* Nicolae Paladi [mailto:n.paladi at gmail.com]
> *Sent:* 30 July 2013 07:25
> *To:* Bryan D. Payne
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] develop a common State of OpenStack
> Security briefing****
>
> ** **
>
> Great initiative, I'd be glad to "test drive" such a presentation at our
> next OpenStack meetup in September;****
>
> ** **
>
> Just my 2 cents: would be good to have a slide or two on the state of VPN
> support in Neutron, as well as what the capabilities of security groups are
> ****
>
> ** **
>
> /nicolae****
>
> ** **
>
> On 29 July 2013 23:56, Bryan D. Payne <bdpayne at acm.org> wrote:****
>
> This sounds very valuable.  What kinds of information would you guys like
> to see in this?****
>
> ** **
>
> Also, I'm thinking the slides could be setup in a way that suits either 30
> min or 60 min presentation lengths.  Does that seem reasonable?****
>
> ** **
>
> -bryan****
>
> ** **
>
> On Mon, Jul 29, 2013 at 12:24 PM, Brian Schott <
> brian.schott at nimbisservices.com> wrote:****
>
> I was thinking that it would be great if we could collectively have a
> common "State of OpenStack Security" that Stackers could give at local
> OpenStack MeetUps or other venues.  This topic comes up all of the time and
> a good executive overview briefing would raise the awareness of what
> OpenStack is doing in this space.  ****
>
> ** **
>
> Is there interest in OSSG in pulling together such a briefing?  ****
>
> Brian****
>
> ** **
>
> -------------------------------------------------****
>
> Brian Schott, CTO****
>
> Nimbis Services, Inc.****
>
> brian.schott at nimbisservices.com****
>
> ph: 443-274-6064  fx: 443-274-6060****
>
> ** **
>
> ** **
>
> ** **
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security****
>
> ** **
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130730/d4c85f04/attachment.html>

From bdpayne at acm.org  Tue Jul 30 22:47:52 2013
From: bdpayne at acm.org (Bryan D. Payne)
Date: Tue, 30 Jul 2013 15:47:52 -0700
Subject: [Openstack-security] graphics help for OSSG logo?
Message-ID: <CAFpPvXBy98hfttVC-DXss3dC+zzRi1uxXOeR4cgDgYw+Uco50Q@mail.gmail.com>

I've been thinking it would be nice to have an OSSG logo.  Perhaps we could
request permission to use the OpenStack logo, altered with a lock/key or
some other security-related iconography.  Or... I'm really open to
suggestions.

Anyone out there good with graphics and willing to help pull this off?

I think that the output would be useful for the OSSG web pages, the slide
deck that we are talking about creating, and other related material.

Cheers,
-bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130730/0235e24f/attachment.html>

From brian.schott at nimbisservices.com  Wed Jul 31 04:44:58 2013
From: brian.schott at nimbisservices.com (Brian Schott)
Date: Wed, 31 Jul 2013 00:44:58 -0400
Subject: [Openstack-security] develop a common State of OpenStack
	Security briefing
In-Reply-To: <CAFpPvXB8VuRdt8XkfYRPq3oa=GvKdgEhQfzgpqy8wKedKo-7CQ@mail.gmail.com>
References: <B543C3BE-B5CA-4AB4-9369-74FEA6E1BFAB@nimbisservices.com>
 <CAFpPvXCesBDfKbe9nXRzcie2bxN-CXqOzAEN-xYBJzs8RtVU8w@mail.gmail.com>
 <CAK0-rpYZmqgUUZ473e8vPms2Z0zyvYiasNm7UqLT5+ayW-ywTg@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A10EC8F012@G4W3202.americas.hpqcorp.net>
 <CAFpPvXB8VuRdt8XkfYRPq3oa=GvKdgEhQfzgpqy8wKedKo-7CQ@mail.gmail.com>
Message-ID: <67694148-B173-4779-ADA0-CA04A1DD5991@nimbisservices.com>

Chris Kemp had some good holistic overview slides at one of the summits that talked about the strength of OpenStack in terms of its plugin architecture and that it is made up of stuff no different than hardening any other IT system.  No magic fix for security, no major barriers for securing deployments, but probably better than your average public facing IT system out of the box.  Good positive message with a dose of there is no such thing as a free lunch.  This could get done in 4-5 slides.  The first slide in this section should be almost a stand-alone summary of the 4-5 slides.

We could have a single service overview slide with a services report card kind of table.  Then maybe have a single status slide for every service and hit those top-level bullets very briefly with a reference to the appropriate hardening guide section or wiki.  We don't have to completely reimplement the security guide, but should then some slides behind each summary slide that tunnels into each of those top-level bullets?  That might be too much.  Things like security bugs can get very stale fast.  


On Jul 30, 2013, at 12:31 PM, Bryan D. Payne <bdpayne at acm.org> wrote:

> I think that it's useful to talk about the "glue components" (e.g., the message queue, database, etc) and current thinking on best practices there.  Also, on best practices for deployment and keeping everything up to date.  Finally, I think it's important to highlight both the good things that we have today, but also the gaps / areas where improvement is needed.
> 
> -bryan
> 
> 
> On Tue, Jul 30, 2013 at 5:00 AM, Clark, Robert Graham <robert.clark at hp.com> wrote:
> I’d certainly be happy to throw some time into this.
> 
>  
> 
> Things I’d expect to see in the deck:
> 
> ·        Holistic overview, general security posture
> 
> ·        Service overview, perhaps restricted to core IaaS services or wider
> 
> o   Covers secure configuration
> 
> o   Especially new options, improvements
> 
> o   Security Bugs
> 
> o   Design issues
> 
> ·        Review of recent security issues and OSSNs
> 
> ·        ?
> 
>  
> 
> From: Nicolae Paladi [mailto:n.paladi at gmail.com] 
> Sent: 30 July 2013 07:25
> To: Bryan D. Payne
> Cc: openstack-security at lists.openstack.org
> Subject: Re: [Openstack-security] develop a common State of OpenStack Security briefing
> 
>  
> 
> Great initiative, I'd be glad to "test drive" such a presentation at our next OpenStack meetup in September;
> 
>  
> 
> Just my 2 cents: would be good to have a slide or two on the state of VPN support in Neutron, as well as what the capabilities of security groups are
> 
>  
> 
> /nicolae
> 
>  
> 
> On 29 July 2013 23:56, Bryan D. Payne <bdpayne at acm.org> wrote:
> 
> This sounds very valuable.  What kinds of information would you guys like to see in this?
> 
>  
> 
> Also, I'm thinking the slides could be setup in a way that suits either 30 min or 60 min presentation lengths.  Does that seem reasonable?
> 
>  
> 
> -bryan
> 
>  
> 
> On Mon, Jul 29, 2013 at 12:24 PM, Brian Schott <brian.schott at nimbisservices.com> wrote:
> 
> I was thinking that it would be great if we could collectively have a common "State of OpenStack Security" that Stackers could give at local OpenStack MeetUps or other venues.  This topic comes up all of the time and a good executive overview briefing would raise the awareness of what OpenStack is doing in this space.  
> 
>  
> 
> Is there interest in OSSG in pulling together such a briefing?  
> 
> Brian
> 
>  
> 
> -------------------------------------------------
> 
> Brian Schott, CTO
> 
> Nimbis Services, Inc.
> 
> brian.schott at nimbisservices.com
> 
> ph: 443-274-6064  fx: 443-274-6060
> 
>  
> 
>  
> 
>  
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 
>  
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 
>  
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130731/dc1c7202/attachment.html>

From 1178032 at bugs.launchpad.net  Wed Jul 31 03:08:17 2013
From: 1178032 at bugs.launchpad.net (OpenStack Hudson)
Date: Wed, 31 Jul 2013 03:08:17 -0000
Subject: [Openstack-security] [Bug 1178032] Re: ldap driver returns hashed
	passwords
References: <20130509001314.14958.69418.malonedeb@gac.canonical.com>
Message-ID: <20130731030817.30116.84117.malone@soybean.canonical.com>

Fix proposed to branch: master
Review: https://review.openstack.org/39406

** Changed in: keystone
       Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1178032

Title:
  ldap driver returns hashed passwords

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  If I'm using the LDAP identity backend, listing group users includes the users' passwords (sha-encoded, but that probably depends on LDAP server configuration).

  Keystone shouldn't be handing out users' passwords.

  The fix is probably to just remove the password attribute. If Keystone
  is just returning all attributes, then it should be changed to only
  return the attributes that are known to be safe.

  Steps to recreate:

  1) start with devstack configured to use LDAP
  # set LDAP options in localrc
  ./stack.sh ...

  2) add the default domain since it doesn't exist by default for some
  reason.

  $ ldapadd -x -D dc=Manager,dc=openstack,dc=org -w ldapadminpwd
  dn: cn=default,ou=Domains,dc=openstack,dc=org
  objectclass: groupOfNames
  member: cn=dummy

  3) Create a couple users

  (set environment variables so you're admin)

  $ keystone user-create --name user1 --pass user1pwd
  (example id is 1db4a4d16ba1458aae139db0f43b0904)
  $ keystone user-create --name user2 --pass user2pwd
  (example id is 4091d11924f5498c8008b655bcf94b9d)

  4) Create a group

  $ ldapadd -x -D dc=Manager,dc=openstack,dc=org -w ldapadminpwd

  dn: ou=UserGroups,dc=openstack,dc=org
  objectclass: organizationalUnit

  dn: cn=group1,ou=UserGroups,dc=openstack,dc=org
  objectclass: groupOfNames
  member: cn=1db4a4d16ba1458aae139db0f43b0904,ou=Users,dc=openstack,dc=org
  member: cn=4091d11924f5498c8008b655bcf94b9d,ou=Users,dc=openstack,dc=org

  5) List the group members:

  $ curl -H "X-Auth-Token: admintoken"
  http://localhost:35357/v3/groups/group1/users | python -m json.tool

  {
      "links": {
          "next": null,
          "previous": null,
          "self": "http://localhost:5000/v3/groups/group1/users"
      },
      "users": [
          {
              "domain_id": "default",
              "id": "1db4a4d16ba1458aae139db0f43b0904",
              "links": {
                  "self": "http://localhost:5000/v3/users/1db4a4d16ba1458aae139db0f43b0904"
              },
              "name": "user1",
              "password": "{SSHA}eQnQSd6SS6tioL/uN4M7odr/cf2SsjbG"
          },
          {
              "domain_id": "default",
              "id": "4091d11924f5498c8008b655bcf94b9d",
              "links": {
                  "self": "http://localhost:5000/v3/users/4091d11924f5498c8008b655bcf94b9d"
              },
              "name": "user2",
              "password": "{SSHA}HDtgM7HcrlXnLM7N85htpz1kKYL2npMS"
          }
      ]
  }

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1178032/+subscriptions



From robert.clark at hp.com  Wed Jul 31 10:47:55 2013
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 31 Jul 2013 10:47:55 +0000
Subject: [Openstack-security] graphics help for OSSG logo?
In-Reply-To: <CAFpPvXBy98hfttVC-DXss3dC+zzRi1uxXOeR4cgDgYw+Uco50Q@mail.gmail.com>
Message-ID: <CE1E9E95.1EBD4%robert.clark@hp.com>

Agreed, we kicked some stuff around in HP a while ago but that was just internal really.

I'll reach out to Stefano and see if we can use the OpenStack artwork as part of our design.

From: Bryan Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>>
Date: Tuesday, 30 July 2013 23:47
To: "openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>" <openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>>
Subject: [Openstack-security] graphics help for OSSG logo?

I've been thinking it would be nice to have an OSSG logo.  Perhaps we could request permission to use the OpenStack logo, altered with a lock/key or some other security-related iconography.  Or... I'm really open to suggestions.

Anyone out there good with graphics and willing to help pull this off?

I think that the output would be useful for the OSSG web pages, the slide deck that we are talking about creating, and other related material.

Cheers,
-bryan



From robert.clark at hp.com  Wed Jul 31 10:53:49 2013
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 31 Jul 2013 10:53:49 +0000
Subject: [Openstack-security] develop a common State of OpenStack
 Security briefing
In-Reply-To: <67694148-B173-4779-ADA0-CA04A1DD5991@nimbisservices.com>
Message-ID: <CE1EAA17.1ECFC%robert.clark@hp.com>

I've not seen the slides so I'm only speaking to your description but I don't think I completely agree with the point that Chris was making back then. There are certain design decisions such as unauthenticated RPC over AMQP that have significant security impact and need to be addressed, some of the 'Glue' that Bryan mentioned below.

It'd be great to see the deck and see which ideas we can bring forward and where we need to highlight the areas of OpenStack that go beyond 'hardening any other IT system'.


From: Brian Schott <brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>>
Date: Wednesday, 31 July 2013 05:44
To: Bryan Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>>
Cc: Robert Clark <robert.clark at hp.com<mailto:robert.clark at hp.com>>, "openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>" <openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>>
Subject: Re: [Openstack-security] develop a common State of OpenStack Security briefing

Chris Kemp had some good holistic overview slides at one of the summits that talked about the strength of OpenStack in terms of its plugin architecture and that it is made up of stuff no different than hardening any other IT system.  No magic fix for security, no major barriers for securing deployments, but probably better than your average public facing IT system out of the box.  Good positive message with a dose of there is no such thing as a free lunch.  This could get done in 4-5 slides.  The first slide in this section should be almost a stand-alone summary of the 4-5 slides.

We could have a single service overview slide with a services report card kind of table.  Then maybe have a single status slide for every service and hit those top-level bullets very briefly with a reference to the appropriate hardening guide section or wiki.  We don't have to completely reimplement the security guide, but should then some slides behind each summary slide that tunnels into each of those top-level bullets?  That might be too much.  Things like security bugs can get very stale fast.


On Jul 30, 2013, at 12:31 PM, Bryan D. Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>> wrote:

I think that it's useful to talk about the "glue components" (e.g., the message queue, database, etc) and current thinking on best practices there.  Also, on best practices for deployment and keeping everything up to date.  Finally, I think it's important to highlight both the good things that we have today, but also the gaps / areas where improvement is needed.

-bryan


On Tue, Jul 30, 2013 at 5:00 AM, Clark, Robert Graham <robert.clark at hp.com<mailto:robert.clark at hp.com>> wrote:
I’d certainly be happy to throw some time into this.

Things I’d expect to see in the deck:

·        Holistic overview, general security posture

·        Service overview, perhaps restricted to core IaaS services or wider

o   Covers secure configuration

o   Especially new options, improvements

o   Security Bugs

o   Design issues

·        Review of recent security issues and OSSNs

·        ?

From: Nicolae Paladi [mailto:n.paladi at gmail.com<mailto:n.paladi at gmail.com>]
Sent: 30 July 2013 07:25
To: Bryan D. Payne
Cc: openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>
Subject: Re: [Openstack-security] develop a common State of OpenStack Security briefing

Great initiative, I'd be glad to "test drive" such a presentation at our next OpenStack meetup in September;

Just my 2 cents: would be good to have a slide or two on the state of VPN support in Neutron, as well as what the capabilities of security groups are

/nicolae

On 29 July 2013 23:56, Bryan D. Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>> wrote:
This sounds very valuable.  What kinds of information would you guys like to see in this?

Also, I'm thinking the slides could be setup in a way that suits either 30 min or 60 min presentation lengths.  Does that seem reasonable?

-bryan

On Mon, Jul 29, 2013 at 12:24 PM, Brian Schott <brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>> wrote:
I was thinking that it would be great if we could collectively have a common "State of OpenStack Security" that Stackers could give at local OpenStack MeetUps or other venues.  This topic comes up all of the time and a good executive overview briefing would raise the awareness of what OpenStack is doing in this space.

Is there interest in OSSG in pulling together such a briefing?
Brian

-------------------------------------------------
Brian Schott, CTO
Nimbis Services, Inc.
brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>
ph: 443-274-6064<tel:443-274-6064>  fx: 443-274-6060<tel:443-274-6060>




_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security


_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security


_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security




From brian.schott at nimbisservices.com  Wed Jul 31 12:51:02 2013
From: brian.schott at nimbisservices.com (Brian Schott)
Date: Wed, 31 Jul 2013 08:51:02 -0400
Subject: [Openstack-security] develop a common State of OpenStack
	Security briefing
In-Reply-To: <CE1EAA17.1ECFC%robert.clark@hp.com>
References: <CE1EAA17.1ECFC%robert.clark@hp.com>
Message-ID: <7F095696-1307-45D9-A580-E6EF99305300@nimbisservices.com>

You can find the talk here:
https://cloudsecurityalliance.org/events/presentation-material/
https://cloudsecurityalliance.org/wp-content/uploads/2011/05/RSA-CSA-Chris-C-Kemp-Keynote-February-2012.pptx

I agree with you on some of the default configuration choices were made without security in mind, but the point I was trying to make is on slide 35.  OpenStack is made up of defensible technologies, but the responsibility is on the deployment.  In some ways, I see this as no different than other web frameworks in their default deployments.

Brian



On Jul 31, 2013, at 6:53 AM, "Clark, Robert Graham" <robert.clark at hp.com> wrote:

> I've not seen the slides so I'm only speaking to your description but I don't think I completely agree with the point that Chris was making back then. There are certain design decisions such as unauthenticated RPC over AMQP that have significant security impact and need to be addressed, some of the 'Glue' that Bryan mentioned below.
> 
> It'd be great to see the deck and see which ideas we can bring forward and where we need to highlight the areas of OpenStack that go beyond 'hardening any other IT system'.
> 
> 
> From: Brian Schott <brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>>
> Date: Wednesday, 31 July 2013 05:44
> To: Bryan Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>>
> Cc: Robert Clark <robert.clark at hp.com<mailto:robert.clark at hp.com>>, "openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>" <openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>>
> Subject: Re: [Openstack-security] develop a common State of OpenStack Security briefing
> 
> Chris Kemp had some good holistic overview slides at one of the summits that talked about the strength of OpenStack in terms of its plugin architecture and that it is made up of stuff no different than hardening any other IT system.  No magic fix for security, no major barriers for securing deployments, but probably better than your average public facing IT system out of the box.  Good positive message with a dose of there is no such thing as a free lunch.  This could get done in 4-5 slides.  The first slide in this section should be almost a stand-alone summary of the 4-5 slides.
> 
> We could have a single service overview slide with a services report card kind of table.  Then maybe have a single status slide for every service and hit those top-level bullets very briefly with a reference to the appropriate hardening guide section or wiki.  We don't have to completely reimplement the security guide, but should then some slides behind each summary slide that tunnels into each of those top-level bullets?  That might be too much.  Things like security bugs can get very stale fast.
> 
> 
> On Jul 30, 2013, at 12:31 PM, Bryan D. Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>> wrote:
> 
> I think that it's useful to talk about the "glue components" (e.g., the message queue, database, etc) and current thinking on best practices there.  Also, on best practices for deployment and keeping everything up to date.  Finally, I think it's important to highlight both the good things that we have today, but also the gaps / areas where improvement is needed.
> 
> -bryan
> 
> 
> On Tue, Jul 30, 2013 at 5:00 AM, Clark, Robert Graham <robert.clark at hp.com<mailto:robert.clark at hp.com>> wrote:
> I’d certainly be happy to throw some time into this.
> 
> Things I’d expect to see in the deck:
> 
> ·        Holistic overview, general security posture
> 
> ·        Service overview, perhaps restricted to core IaaS services or wider
> 
> o   Covers secure configuration
> 
> o   Especially new options, improvements
> 
> o   Security Bugs
> 
> o   Design issues
> 
> ·        Review of recent security issues and OSSNs
> 
> ·        ?
> 
> From: Nicolae Paladi [mailto:n.paladi at gmail.com<mailto:n.paladi at gmail.com>]
> Sent: 30 July 2013 07:25
> To: Bryan D. Payne
> Cc: openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>
> Subject: Re: [Openstack-security] develop a common State of OpenStack Security briefing
> 
> Great initiative, I'd be glad to "test drive" such a presentation at our next OpenStack meetup in September;
> 
> Just my 2 cents: would be good to have a slide or two on the state of VPN support in Neutron, as well as what the capabilities of security groups are
> 
> /nicolae
> 
> On 29 July 2013 23:56, Bryan D. Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>> wrote:
> This sounds very valuable.  What kinds of information would you guys like to see in this?
> 
> Also, I'm thinking the slides could be setup in a way that suits either 30 min or 60 min presentation lengths.  Does that seem reasonable?
> 
> -bryan
> 
> On Mon, Jul 29, 2013 at 12:24 PM, Brian Schott <brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>> wrote:
> I was thinking that it would be great if we could collectively have a common "State of OpenStack Security" that Stackers could give at local OpenStack MeetUps or other venues.  This topic comes up all of the time and a good executive overview briefing would raise the awareness of what OpenStack is doing in this space.
> 
> Is there interest in OSSG in pulling together such a briefing?
> Brian
> 
> -------------------------------------------------
> Brian Schott, CTO
> Nimbis Services, Inc.
> brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>
> ph: 443-274-6064<tel:443-274-6064>  fx: 443-274-6060<tel:443-274-6060>
> 
> 
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 




From 1192971 at bugs.launchpad.net  Wed Jul 31 13:54:03 2013
From: 1192971 at bugs.launchpad.net (OpenStack Hudson)
Date: Wed, 31 Jul 2013 13:54:03 -0000
Subject: [Openstack-security] [Bug 1192971] Fix proposed to cinder (master)
References: <20130620133506.19620.30523.malonedeb@gac.canonical.com>
Message-ID: <20130731135403.890.6652.malone@wampee.canonical.com>

Fix proposed to branch: master
Review: https://review.openstack.org/39485

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1192971

Title:
  Command execution cases need to be strengthened

Status in Cinder:
  In Progress
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Grant Murphy from Red Hat Product Security Team reports the following
  potential vulnerability:

  For the most part OpenStack seems to do command execution safely using
  subprocess.Popen. There are two instances where things become a little
  dubious. The first is when shell=True is used with subprocess. This
  doesn't prevent arguments being supplied that allow for multiple
  commands to be executed. e.g. '; cat /etc/passwd'. The second case is
  where commands are made to an external ssh host.

  See attached file for a lit of potential injections: we should double-
  check them (even if I expect most of them to turn false positive)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1192971/+subscriptions



From robert.clark at hp.com  Wed Jul 31 14:50:29 2013
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 31 Jul 2013 14:50:29 +0000
Subject: [Openstack-security] develop a common State of OpenStack
 Security briefing
In-Reply-To: <7F095696-1307-45D9-A580-E6EF99305300@nimbisservices.com>
Message-ID: <CE1EE222.1EF69%robert.clark@hp.com>

Interesting deck although I think it's a mistake to believe that OpenStack
itself is made out of 'defensible' technologies and the only requirement
is to turn on the correct 'switches'.

This is certainly the case in a lot of the technologies used and a large
degree of what the security guide addresses is exactly this - flipping the
right switches to secure your deployment. However there are a bunch of
design decisions that need to be revisited because the security impact is
significant and the effort required to fix can be very high.


On 31/07/2013 13:51, "Brian Schott" <brian.schott at nimbisservices.com>
wrote:

>You can find the talk here:
>https://cloudsecurityalliance.org/events/presentation-material/
>https://cloudsecurityalliance.org/wp-content/uploads/2011/05/RSA-CSA-Chris
>-C-Kemp-Keynote-February-2012.pptx
>
>I agree with you on some of the default configuration choices were made
>without security in mind, but the point I was trying to make is on slide
>35.  OpenStack is made up of defensible technologies, but the
>responsibility is on the deployment.  In some ways, I see this as no
>different than other web frameworks in their default deployments.
>
>Brian
>
>
>
>On Jul 31, 2013, at 6:53 AM, "Clark, Robert Graham" <robert.clark at hp.com>
>wrote:
>
>> I've not seen the slides so I'm only speaking to your description but I
>>don't think I completely agree with the point that Chris was making back
>>then. There are certain design decisions such as unauthenticated RPC
>>over AMQP that have significant security impact and need to be
>>addressed, some of the 'Glue' that Bryan mentioned below.
>> 
>> It'd be great to see the deck and see which ideas we can bring forward
>>and where we need to highlight the areas of OpenStack that go beyond
>>'hardening any other IT system'.
>> 
>> 
>> From: Brian Schott
>><brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>>
>> Date: Wednesday, 31 July 2013 05:44
>> To: Bryan Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>>
>> Cc: Robert Clark <robert.clark at hp.com<mailto:robert.clark at hp.com>>,
>>"openstack-security at lists.openstack.org<mailto:openstack-security at lists.o
>>penstack.org>" 
>><openstack-security at lists.openstack.org<mailto:openstack-security at lists.o
>>penstack.org>>
>> Subject: Re: [Openstack-security] develop a common State of OpenStack
>>Security briefing
>> 
>> Chris Kemp had some good holistic overview slides at one of the summits
>>that talked about the strength of OpenStack in terms of its plugin
>>architecture and that it is made up of stuff no different than hardening
>>any other IT system.  No magic fix for security, no major barriers for
>>securing deployments, but probably better than your average public
>>facing IT system out of the box.  Good positive message with a dose of
>>there is no such thing as a free lunch.  This could get done in 4-5
>>slides.  The first slide in this section should be almost a stand-alone
>>summary of the 4-5 slides.
>> 
>> We could have a single service overview slide with a services report
>>card kind of table.  Then maybe have a single status slide for every
>>service and hit those top-level bullets very briefly with a reference to
>>the appropriate hardening guide section or wiki.  We don't have to
>>completely reimplement the security guide, but should then some slides
>>behind each summary slide that tunnels into each of those top-level
>>bullets?  That might be too much.  Things like security bugs can get
>>very stale fast.
>> 
>> 
>> On Jul 30, 2013, at 12:31 PM, Bryan D. Payne
>><bdpayne at acm.org<mailto:bdpayne at acm.org>> wrote:
>> 
>> I think that it's useful to talk about the "glue components" (e.g., the
>>message queue, database, etc) and current thinking on best practices
>>there.  Also, on best practices for deployment and keeping everything up
>>to date.  Finally, I think it's important to highlight both the good
>>things that we have today, but also the gaps / areas where improvement
>>is needed.
>> 
>> -bryan
>> 
>> 
>> On Tue, Jul 30, 2013 at 5:00 AM, Clark, Robert Graham
>><robert.clark at hp.com<mailto:robert.clark at hp.com>> wrote:
>> I¹d certainly be happy to throw some time into this.
>> 
>> Things I¹d expect to see in the deck:
>> 
>> ·        Holistic overview, general security posture
>> 
>> ·        Service overview, perhaps restricted to core IaaS services or
>>wider
>> 
>> o   Covers secure configuration
>> 
>> o   Especially new options, improvements
>> 
>> o   Security Bugs
>> 
>> o   Design issues
>> 
>> ·        Review of recent security issues and OSSNs
>> 
>> ·        ?
>> 
>> From: Nicolae Paladi
>>[mailto:n.paladi at gmail.com<mailto:n.paladi at gmail.com>]
>> Sent: 30 July 2013 07:25
>> To: Bryan D. Payne
>> Cc: 
>>openstack-security at lists.openstack.org<mailto:openstack-security at lists.op
>>enstack.org>
>> Subject: Re: [Openstack-security] develop a common State of OpenStack
>>Security briefing
>> 
>> Great initiative, I'd be glad to "test drive" such a presentation at
>>our next OpenStack meetup in September;
>> 
>> Just my 2 cents: would be good to have a slide or two on the state of
>>VPN support in Neutron, as well as what the capabilities of security
>>groups are
>> 
>> /nicolae
>> 
>> On 29 July 2013 23:56, Bryan D. Payne
>><bdpayne at acm.org<mailto:bdpayne at acm.org>> wrote:
>> This sounds very valuable.  What kinds of information would you guys
>>like to see in this?
>> 
>> Also, I'm thinking the slides could be setup in a way that suits either
>>30 min or 60 min presentation lengths.  Does that seem reasonable?
>> 
>> -bryan
>> 
>> On Mon, Jul 29, 2013 at 12:24 PM, Brian Schott
>><brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>>
>> wrote:
>> I was thinking that it would be great if we could collectively have a
>>common "State of OpenStack Security" that Stackers could give at local
>>OpenStack MeetUps or other venues.  This topic comes up all of the time
>>and a good executive overview briefing would raise the awareness of what
>>OpenStack is doing in this space.
>> 
>> Is there interest in OSSG in pulling together such a briefing?
>> Brian
>> 
>> -------------------------------------------------
>> Brian Schott, CTO
>> Nimbis Services, Inc.
>> brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>
>> ph: 443-274-6064<tel:443-274-6064>  fx: 443-274-6060<tel:443-274-6060>
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Openstack-security mailing list
>> 
>>Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.op
>>enstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>> 
>> 
>> _______________________________________________
>> Openstack-security mailing list
>> 
>>Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.op
>>enstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>> 
>> 
>> _______________________________________________
>> Openstack-security mailing list
>> 
>>Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.op
>>enstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>> 
>




From thomas at suse.de  Wed Jul 31 19:35:49 2013
From: thomas at suse.de (Thomas Biege)
Date: Wed, 31 Jul 2013 21:35:49 +0200
Subject: [Openstack-security] develop a common State of OpenStack
 Security briefing
In-Reply-To: <CAFpPvXB8VuRdt8XkfYRPq3oa=GvKdgEhQfzgpqy8wKedKo-7CQ@mail.gmail.com>
References: <B543C3BE-B5CA-4AB4-9369-74FEA6E1BFAB@nimbisservices.com>
 <CAFpPvXCesBDfKbe9nXRzcie2bxN-CXqOzAEN-xYBJzs8RtVU8w@mail.gmail.com>
 <CAK0-rpYZmqgUUZ473e8vPms2Z0zyvYiasNm7UqLT5+ayW-ywTg@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A10EC8F012@G4W3202.americas.hpqcorp.net>
 <CAFpPvXB8VuRdt8XkfYRPq3oa=GvKdgEhQfzgpqy8wKedKo-7CQ@mail.gmail.com>
Message-ID: <51F96715.8060602@suse.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Am 30.07.2013 18:31, schrieb Bryan D. Payne:
> I think that it's useful to talk about the "glue components" (e.g.,
> the message queue, database, etc) and current thinking on best
> practices there.  Also, on best practices for deployment and
> keeping everything up to date.  Finally, I think it's important to
> highlight both the good things that we have today, but also the
> gaps / areas where improvement is needed.

in general such a list of open topics would be helpful to see what
idle hands could do.

Best,
Thomas

> 
> -bryan
> 
> 
> On Tue, Jul 30, 2013 at 5:00 AM, Clark, Robert Graham 
> <robert.clark at hp.com <mailto:robert.clark at hp.com>> wrote:
> 
> I’d certainly be happy to throw some time into this.____
> 
> __ __
> 
> Things I’d expect to see in the deck:____
> 
> __·        __Holistic overview, general security posture____
> 
> __·        __Service overview, perhaps restricted to core IaaS 
> services or wider____
> 
> __o   __Covers secure configuration____
> 
> __o   __Especially new options, improvements____
> 
> __o   __Security Bugs____
> 
> __o   __Design issues____
> 
> __·        __Review of recent security issues and OSSNs____
> 
> __·        __?____
> 
> __ __
> 
> *From:*Nicolae Paladi [mailto:n.paladi at gmail.com 
> <mailto:n.paladi at gmail.com>] *Sent:* 30 July 2013 07:25 *To:* Bryan
> D. Payne *Cc:* openstack-security at lists.openstack.org 
> <mailto:openstack-security at lists.openstack.org> *Subject:* Re:
> [Openstack-security] develop a common State of OpenStack Security
> briefing____
> 
> __ __
> 
> Great initiative, I'd be glad to "test drive" such a presentation
> at our next OpenStack meetup in September;____
> 
> __ __
> 
> Just my 2 cents: would be good to have a slide or two on the state 
> of VPN support in Neutron, as well as what the capabilities of 
> security groups are____
> 
> __ __
> 
> /nicolae____
> 
> __ __
> 
> On 29 July 2013 23:56, Bryan D. Payne <bdpayne at acm.org 
> <mailto:bdpayne at acm.org>> wrote:____
> 
> This sounds very valuable.  What kinds of information would you
> guys like to see in this?____
> 
> __ __
> 
> Also, I'm thinking the slides could be setup in a way that suits 
> either 30 min or 60 min presentation lengths.  Does that seem 
> reasonable?____
> 
> __ __
> 
> -bryan____
> 
> __ __
> 
> On Mon, Jul 29, 2013 at 12:24 PM, Brian Schott 
> <brian.schott at nimbisservices.com 
> <mailto:brian.schott at nimbisservices.com>> wrote:____
> 
> I was thinking that it would be great if we could collectively
> have a common "State of OpenStack Security" that Stackers could
> give at local OpenStack MeetUps or other venues.  This topic comes
> up all of the time and a good executive overview briefing would
> raise the awareness of what OpenStack is doing in this space.
> ____
> 
> __ __
> 
> Is there interest in OSSG in pulling together such a briefing?
> ____
> 
> Brian____
> 
> __ __
> 
> -------------------------------------------------____
> 
> Brian Schott, CTO____
> 
> Nimbis Services, Inc.____
> 
> brian.schott at nimbisservices.com 
> <mailto:brian.schott at nimbisservices.com>____
> 
> ph: 443-274-6064 <tel:443-274-6064>  fx: 443-274-6060 
> <tel:443-274-6060>____
> 
> __ __
> 
> __ __
> 
> __ __
> 
> 
> _______________________________________________ Openstack-security
> mailing list Openstack-security at lists.openstack.org 
> <mailto:Openstack-security at lists.openstack.org> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security____
>
>  __ __
> 
> 
> _______________________________________________ Openstack-security
> mailing list Openstack-security at lists.openstack.org 
> <mailto:Openstack-security at lists.openstack.org> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security____
>
>  __ __
> 
> 
> 
> 
> _______________________________________________ Openstack-security
> mailing list Openstack-security at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
> 
- -- 
Thomas Biege <thomas at suse.de>, Team Leader MaintenanceSecurity, CSSLP
SUSE LINUX Products GmbH
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
HRB 21284 (AG Nürnberg)
- --
  Wer aufhoert besser werden zu wollen, hoert auf gut zu sein.
                            -- Marie von Ebner-Eschenbach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJR+WcVAAoJEJqHoVJVjr8Dp0gH/j4ByWaaSDpv+3nPlBbT8liJ
z9weuRk5hhVJkxjC6RF1ZslGPNKCc1reRZDoA2G0u0oadYbQYWWGi+zq9pw6kPPK
b5ZCRn55ryROowmOjZKWUJEsOHGTiR+VrKnV3iPN/xoc77H08LSO4UGh4fzhBqQV
Dc6VoXHvnjS+M3gfb2S10A2wbu9jP3nsWUqLtyRMv+RNW123/K12LK8k+fi5FqpJ
ZOPO9EK5mkz1J/A032/TPP+zFvZORWbcLwyd9Mww9psWEook1Ii35z7BEZjHBpHS
mWAqwF/2/7LZrLJLbV1H8Oe/jrfbW8nBIqV74ECey94sJnmeXse4So7bZv5tvsw=
=KUk6
-----END PGP SIGNATURE-----



From brian.schott at nimbisservices.com  Wed Jul 31 22:43:50 2013
From: brian.schott at nimbisservices.com (Brian Schott)
Date: Wed, 31 Jul 2013 15:43:50 -0700 (PDT)
Subject: [Openstack-security] develop a common State of OpenStack
 Security briefing
In-Reply-To: <CE1EE222.1EF69%robert.clark@hp.com>
References: <CE1EE222.1EF69%robert.clark@hp.com>
Message-ID: <1375310629814.e6865048@Nodemailer>

This was February 2012, so it is also a bit out of date and may suffer from CEOptimism (a common enough affliction :-).  


I'm more aware of the and some of the design changes this group is recommending after participating in the doc sprint, but I'd also argue that a deployment team has a better chance of hardening OpenStack over the proprietary or open-core alternatives.


It also depends on the use case for the deployment.  Behind their corporate firewall for internal use only, OpenStack is probably much safer than their existing IT infrastructure.  Nothing like clear-text VNC sessions to improve security.


The talk should try to score base OpenStack deployments for different use cases, summarize deployment recommendations for each, and talk about current and future efforts planned by the community.  
—
Sent from Mailbox for iPad

On Wed, Jul 31, 2013 at 10:51 AM, Clark, Robert Graham
<robert.clark at hp.com> wrote:

> Interesting deck although I think it's a mistake to believe that OpenStack
> itself is made out of 'defensible' technologies and the only requirement
> is to turn on the correct 'switches'.
> This is certainly the case in a lot of the technologies used and a large
> degree of what the security guide addresses is exactly this - flipping the
> right switches to secure your deployment. However there are a bunch of
> design decisions that need to be revisited because the security impact is
> significant and the effort required to fix can be very high.
> On 31/07/2013 13:51, "Brian Schott" <brian.schott at nimbisservices.com>
> wrote:
>>You can find the talk here:
>>https://cloudsecurityalliance.org/events/presentation-material/
>>https://cloudsecurityalliance.org/wp-content/uploads/2011/05/RSA-CSA-Chris
>>-C-Kemp-Keynote-February-2012.pptx
>>
>>I agree with you on some of the default configuration choices were made
>>without security in mind, but the point I was trying to make is on slide
>>35.  OpenStack is made up of defensible technologies, but the
>>responsibility is on the deployment.  In some ways, I see this as no
>>different than other web frameworks in their default deployments.
>>
>>Brian
>>
>>
>>
>>On Jul 31, 2013, at 6:53 AM, "Clark, Robert Graham" <robert.clark at hp.com>
>>wrote:
>>
>>> I've not seen the slides so I'm only speaking to your description but I
>>>don't think I completely agree with the point that Chris was making back
>>>then. There are certain design decisions such as unauthenticated RPC
>>>over AMQP that have significant security impact and need to be
>>>addressed, some of the 'Glue' that Bryan mentioned below.
>>> 
>>> It'd be great to see the deck and see which ideas we can bring forward
>>>and where we need to highlight the areas of OpenStack that go beyond
>>>'hardening any other IT system'.
>>> 
>>> 
>>> From: Brian Schott
>>><brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>>
>>> Date: Wednesday, 31 July 2013 05:44
>>> To: Bryan Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>>
>>> Cc: Robert Clark <robert.clark at hp.com<mailto:robert.clark at hp.com>>,
>>>"openstack-security at lists.openstack.org<mailto:openstack-security at lists.o
>>>penstack.org>" 
>>><openstack-security at lists.openstack.org<mailto:openstack-security at lists.o
>>>penstack.org>>
>>> Subject: Re: [Openstack-security] develop a common State of OpenStack
>>>Security briefing
>>> 
>>> Chris Kemp had some good holistic overview slides at one of the summits
>>>that talked about the strength of OpenStack in terms of its plugin
>>>architecture and that it is made up of stuff no different than hardening
>>>any other IT system.  No magic fix for security, no major barriers for
>>>securing deployments, but probably better than your average public
>>>facing IT system out of the box.  Good positive message with a dose of
>>>there is no such thing as a free lunch.  This could get done in 4-5
>>>slides.  The first slide in this section should be almost a stand-alone
>>>summary of the 4-5 slides.
>>> 
>>> We could have a single service overview slide with a services report
>>>card kind of table.  Then maybe have a single status slide for every
>>>service and hit those top-level bullets very briefly with a reference to
>>>the appropriate hardening guide section or wiki.  We don't have to
>>>completely reimplement the security guide, but should then some slides
>>>behind each summary slide that tunnels into each of those top-level
>>>bullets?  That might be too much.  Things like security bugs can get
>>>very stale fast.
>>> 
>>> 
>>> On Jul 30, 2013, at 12:31 PM, Bryan D. Payne
>>><bdpayne at acm.org<mailto:bdpayne at acm.org>> wrote:
>>> 
>>> I think that it's useful to talk about the "glue components" (e.g., the
>>>message queue, database, etc) and current thinking on best practices
>>>there.  Also, on best practices for deployment and keeping everything up
>>>to date.  Finally, I think it's important to highlight both the good
>>>things that we have today, but also the gaps / areas where improvement
>>>is needed.
>>> 
>>> -bryan
>>> 
>>> 
>>> On Tue, Jul 30, 2013 at 5:00 AM, Clark, Robert Graham
>>><robert.clark at hp.com<mailto:robert.clark at hp.com>> wrote:
>>> I¹d certainly be happy to throw some time into this.
>>> 
>>> Things I¹d expect to see in the deck:
>>> 
>>> ·        Holistic overview, general security posture
>>> 
>>> ·        Service overview, perhaps restricted to core IaaS services or
>>>wider
>>> 
>>> o   Covers secure configuration
>>> 
>>> o   Especially new options, improvements
>>> 
>>> o   Security Bugs
>>> 
>>> o   Design issues
>>> 
>>> ·        Review of recent security issues and OSSNs
>>> 
>>> ·        ?
>>> 
>>> From: Nicolae Paladi
>>>[mailto:n.paladi at gmail.com<mailto:n.paladi at gmail.com>]
>>> Sent: 30 July 2013 07:25
>>> To: Bryan D. Payne
>>> Cc: 
>>>openstack-security at lists.openstack.org<mailto:openstack-security at lists.op
>>>enstack.org>
>>> Subject: Re: [Openstack-security] develop a common State of OpenStack
>>>Security briefing
>>> 
>>> Great initiative, I'd be glad to "test drive" such a presentation at
>>>our next OpenStack meetup in September;
>>> 
>>> Just my 2 cents: would be good to have a slide or two on the state of
>>>VPN support in Neutron, as well as what the capabilities of security
>>>groups are
>>> 
>>> /nicolae
>>> 
>>> On 29 July 2013 23:56, Bryan D. Payne
>>><bdpayne at acm.org<mailto:bdpayne at acm.org>> wrote:
>>> This sounds very valuable.  What kinds of information would you guys
>>>like to see in this?
>>> 
>>> Also, I'm thinking the slides could be setup in a way that suits either
>>>30 min or 60 min presentation lengths.  Does that seem reasonable?
>>> 
>>> -bryan
>>> 
>>> On Mon, Jul 29, 2013 at 12:24 PM, Brian Schott
>>><brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>>
>>> wrote:
>>> I was thinking that it would be great if we could collectively have a
>>>common "State of OpenStack Security" that Stackers could give at local
>>>OpenStack MeetUps or other venues.  This topic comes up all of the time
>>>and a good executive overview briefing would raise the awareness of what
>>>OpenStack is doing in this space.
>>> 
>>> Is there interest in OSSG in pulling together such a briefing?
>>> Brian
>>> 
>>> -------------------------------------------------
>>> Brian Schott, CTO
>>> Nimbis Services, Inc.
>>> brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>
>>> ph: 443-274-6064<tel:443-274-6064>  fx: 443-274-6060<tel:443-274-6060>
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Openstack-security mailing list
>>> 
>>>Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.op
>>>enstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>> 
>>> 
>>> _______________________________________________
>>> Openstack-security mailing list
>>> 
>>>Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.op
>>>enstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>> 
>>> 
>>> _______________________________________________
>>> Openstack-security mailing list
>>> 
>>>Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.op
>>>enstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>> 
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130731/7ebe7c15/attachment.html>