From m.koderer at telekom.de Wed Feb 5 14:54:36 2014 From: m.koderer at telekom.de (Koderer, Marc) Date: Wed, 5 Feb 2014 15:54:36 +0100 Subject: [Openstack-security] Fuzzy test framework in Tempest Message-ID: Hello Security Team, David and I are currently working on an automated framework for negative testing in Tempest. This frameworks generates tests out of json schema definitions (see https://review.openstack.org/#/c/64733/ and https://blueprints.launchpad.net/tempest/+spec/negative-tests). During discussion we came to the idea that it would be quite easy to build a security fuzzy test framework out of existing pieces in Tempest. If we'd run the negative tests in our stress test framework that launches a certain number of concurrent worker processes. At the end of a run we could use Tempest again to validate that all services are up and running. Is this topic potentially interesting for this group? I saw on your launchpad task board that your are planning something similar: "Develop stress tests that can be integrated with current testing" Did somebody already spend some effort in that area? I'd like to join your meeting tomorrow and discuss about it. Regards Marc DEUTSCHE TELEKOM AG Digital Business Unit, Cloud Services (P&I) Marc Koderer Cloud Technology Software Developer T-Online-Allee 1, 64211 Darmstadt E-Mail: m.koderer at telekom.de www.telekom.com LIFE IS FOR SHARING. DEUTSCHE TELEKOM AG Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) Board of Management: René Obermann (Chairman), Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick Commercial register: Amtsgericht Bonn HRB 6794 Registered office: Bonn BIG CHANGES START SMALL – CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. From bdpayne at acm.org Wed Feb 5 17:57:00 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Wed, 5 Feb 2014 09:57:00 -0800 Subject: [Openstack-security] Fuzzy test framework in Tempest In-Reply-To: References: Message-ID: Marc, This is certainly of interest to OSSG. There were some people talking about doing security testing before the last summit, but I haven't heard much about that recently. Please do join us for the meeting tomorrow and we can discuss in some more detail. I'll see if I can encourage the other parties to participate as well. Cheers, -bryan On Wed, Feb 5, 2014 at 6:54 AM, Koderer, Marc wrote: > Hello Security Team, > > David and I are currently working on an automated framework for negative > testing in Tempest. This frameworks generates tests out of json schema > definitions (see https://review.openstack.org/#/c/64733/ and > https://blueprints.launchpad.net/tempest/+spec/negative-tests). > > During discussion we came to the idea that it would be quite easy to build > a > security fuzzy test framework out of existing pieces in Tempest. If we'd > run > the negative tests in our stress test framework that launches a certain > number > of concurrent worker processes. At the end of a run we could use Tempest > again > to validate that all services are up and running. > > Is this topic potentially interesting for this group? > I saw on your launchpad task board that your are planning something > similar: > "Develop stress tests that can be integrated with current testing" > Did somebody already spend some effort in that area? > > I'd like to join your meeting tomorrow and discuss about it. > > Regards > Marc > > DEUTSCHE TELEKOM AG > Digital Business Unit, Cloud Services (P&I) > Marc Koderer > Cloud Technology Software Developer > T-Online-Allee 1, 64211 Darmstadt > E-Mail: m.koderer at telekom.de > www.telekom.com > > LIFE IS FOR SHARING. > > DEUTSCHE TELEKOM AG > Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) > Board of Management: René Obermann (Chairman), > Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, > Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick > Commercial register: Amtsgericht Bonn HRB 6794 > Registered office: Bonn > > BIG CHANGES START SMALL - CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. > _______________________________________________ > 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: From gerrit2 at review.openstack.org Thu Feb 6 19:56:42 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 06 Feb 2014 19:56:42 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/70228 Log: commit 2986500d5c69fd6f277d872e9e1c58fedcf175d9 Author: Kaitlin Farr Date: Mon Feb 3 12:16:51 2014 -0500 Adds ephemeral storage encryption for Raw back-end images This patch adds ephemeral storage encryption for Raw back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue is not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Change-Id: I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Implements: blueprint encrypt-ephemeral-storage DocImpact SecurityImpact From gerrit2 at review.openstack.org Thu Feb 6 21:32:57 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 06 Feb 2014 21:32:57 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/70228 Log: commit b3115a368741f8fe01c07e0880dfb26df7008f67 Author: Kaitlin Farr Date: Mon Feb 3 12:16:51 2014 -0500 Adds ephemeral storage encryption for Raw back-end images This patch adds ephemeral storage encryption for Raw back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue is not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Change-Id: I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Implements: blueprint encrypt-ephemeral-storage DocImpact SecurityImpact From gerrit2 at review.openstack.org Thu Feb 6 23:07:08 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 06 Feb 2014 23:07:08 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/70228 Log: commit f76ad814b419d83fe772528608672a97313b9262 Author: Kaitlin Farr Date: Mon Feb 3 12:16:51 2014 -0500 Adds ephemeral storage encryption for Raw back-end images This patch adds ephemeral storage encryption for Raw back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue is not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Change-Id: I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Implements: blueprint encrypt-ephemeral-storage DocImpact SecurityImpact From gerrit2 at review.openstack.org Thu Feb 6 23:35:22 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 06 Feb 2014 23:35:22 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/70228 Log: commit 9068fe16f5eb614fe0c4e255d3b5ad00cb24bfdb Author: Kaitlin Farr Date: Mon Feb 3 12:16:51 2014 -0500 Adds ephemeral storage encryption for Raw back-end images This patch adds ephemeral storage encryption for Raw back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue is not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Change-Id: I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Implements: blueprint encrypt-ephemeral-storage DocImpact SecurityImpact From john at johngarbutt.com Fri Feb 7 13:45:20 2014 From: john at johngarbutt.com (John Garbutt) Date: Fri, 07 Feb 2014 13:45:20 -0000 Subject: [Openstack-security] [Bug 1252519] Re: Live migration failed because of file permission changed References: <20131119003108.27374.76789.malonedeb@gac.canonical.com> Message-ID: <20140207134521.1483.12113.launchpad@wampee.canonical.com> ** Tags added: compute live-migrate ** Tags added: security ** Changed in: nova Importance: Undecided => Medium ** Changed in: nova Status: New => Triaged ** Tags added: libvirt -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1252519 Title: Live migration failed because of file permission changed Status in OpenStack Compute (Nova): Triaged Bug description: Openstack : Havana OS : CentOS 6.4 Shared storage with GlusterFS : /var/lib/nova/instances mounted on glusterfs shared Instance start up fine on node01. When live migration happen, it moved to node02 but failed with the following error 2013-11-18 16:27:37.813 9837 ERROR nova.openstack.common.periodic_task [-] Error during ComputeManager.update_available_resource: Unexpected error while running command. Command: env LC_ALL=C LANG=C qemu-img info /var/lib/nova/instances/aa1deb40-ae1d-45e4-a37e-7b0607df372f/disk Exit code: 1 Stdout: '' Stderr: "qemu-img: Could not open '/var/lib/nova/instances/aa1deb40-ae1d-45e4-a37e-7b0607df372f/disk'\n" 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task Traceback (most recent call last): 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task File "/usr/lib/python2.6/site-packages/nova/openstack/common/periodic_task.py", line 180, in run_periodic_tasks 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task task(self, context) The problem is with the file ownership of "console.log" and "disk". Those file should be owned by user "qemu" and group "qemu" but after the migration, both files are owned by root drwxr-xr-x 2 nova nova 53 Nov 18 13:40 . drwxr-xr-x 6 nova nova 110 Nov 18 13:43 .. -rw-rw---- 1 root root 1546 Nov 18 13:43 console.log -rw-r--r-- 1 root root 12058624 Nov 18 13:42 disk -rw-r--r-- 1 nova nova 1569 Nov 18 13:42 libvirt.xml To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1252519/+subscriptions From thierry.carrez+lp at gmail.com Fri Feb 7 14:35:31 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 07 Feb 2014 14:35:31 -0000 Subject: [Openstack-security] [Bug 1081795] Re: Nova rootwrap is too permissive with iproute(2) arguments References: <20121121214352.19413.92008.malonedeb@wampee.canonical.com> Message-ID: <20140207143532.1935.38166.malone@soybean.canonical.com> Rewritten as a oslo.rootwrap bug. ** Project changed: nova => oslo ** Changed in: oslo Importance: Wishlist => High ** Changed in: oslo Status: In Progress => Triaged ** Changed in: oslo Assignee: Mark McClain (markmcclain) => (unassigned) ** Summary changed: - Nova rootwrap is too permissive with iproute(2) arguments + IpFilter fails to prevent ip netns exec ** Summary changed: - IpFilter fails to prevent ip netns exec + oslo.rootwrap IpFilter fails to prevent ip netns exec ** Description changed: - The Nova rootwrap filters allow the nova user to spawn an unrestricted - root shell. This is a problem that we fixed in Quantum over the summer, - so I've got code to close the hole. + This is an oslo.rootwrap bug. + IpFilter is designed to allow any ip command, unless the second + parameter is "netns" (in which case you only allow ip netns + {list,add,delete}. - vagrant at vagrant-precise:~/devstack$ sudo /usr/local/bin/nova-rootwrap /etc/nova/rootwrap.conf ip netns add foo - vagrant at vagrant-precise:~/devstack$ sudo /usr/local/bin/nova-rootwrap /etc/nova/rootwrap.conf ip netns exec foo bash - root at vagrant-precise:~/devstack# whoami - root - root at vagrant-precise:~/devstack# exit - exit - vagrant at vagrant-precise:~/devstack$ + The trick is it's trivial to work around this (just run 'ip -s netns + exec'). - - For contrast here's how the Quantum wrapper behaves: - - vagrant at vagrant-precise:~/devstack$ sudo /usr/local/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ip netns add foo - vagrant at vagrant-precise:~/devstack$ sudo /usr/local/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ip netns exec foo bash - Unauthorized command: ip netns exec foo bash - vagrant at vagrant-precise:~/devstack$ + Once that's fixed, Nova should update from using a CommandFilter to + using the IpFilter for calling 'ip'. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1081795 Title: oslo.rootwrap IpFilter fails to prevent ip netns exec Status in Oslo - a Library of Common OpenStack Code: Triaged Bug description: This is an oslo.rootwrap bug. IpFilter is designed to allow any ip command, unless the second parameter is "netns" (in which case you only allow ip netns {list,add,delete}. The trick is it's trivial to work around this (just run 'ip -s netns exec'). Once that's fixed, Nova should update from using a CommandFilter to using the IpFilter for calling 'ip'. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1081795/+subscriptions From thierry.carrez+lp at gmail.com Fri Feb 7 14:44:39 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 07 Feb 2014 14:44:39 -0000 Subject: [Openstack-security] [Bug 1081795] Re: oslo.rootwrap IpFilter fails to prevent ip netns exec References: <20121121214352.19413.92008.malonedeb@wampee.canonical.com> Message-ID: <20140207144439.1458.17021.malone@gac.canonical.com> It looks like you can't have parameters between netns and exec, so we could check for presence of ['netns', 'exec'] slice within the arg list. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1081795 Title: oslo.rootwrap IpFilter fails to prevent ip netns exec Status in Oslo - a Library of Common OpenStack Code: Triaged Bug description: This is an oslo.rootwrap bug. IpFilter is designed to allow any ip command, unless the second parameter is "netns" (in which case you only allow ip netns {list,add,delete}. The trick is it's trivial to work around this (just run 'ip -s netns exec'). Once that's fixed, Nova should update from using a CommandFilter to using the IpFilter for calling 'ip'. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1081795/+subscriptions From ahmed.shohel at ericsson.com Mon Feb 10 14:19:33 2014 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Mon, 10 Feb 2014 16:19:33 +0200 Subject: [Openstack-security] Authentication token generation using UUID Message-ID: <6F6793DD-BC97-443E-A0FD-F523CEF4B84D@ericsson.com> Hi, Currently, Keystone Token provider (both PKI and UUID) relies on uuid.uuid4 to generate token which is used as an authentication token during its lifetime. def _get_token_id(self, token_data): return uuid.uuid4().hex My question is how secure is UUID4 token. According to RFC 4122 "Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access)" The implementation of UUID4 relies on os.urandom() which provides pretty good randomness. However, there are still concerns about its randomness. See the thread here http://stackoverflow.com/questions/817882/unique-session-id-in-python. Should it be a security bug for keystone ? If it is, both PKI and UUID token generation process is vulnerable. ...shohel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4163 bytes Desc: not available URL: From thierry.carrez+lp at gmail.com Mon Feb 10 15:45:13 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 10 Feb 2014 15:45:13 -0000 Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set insecure file permissions References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com> Message-ID: <20140210154514.2150.77292.launchpad@gac.canonical.com> ** Information type changed from Private Security to Public ** Tags added: security ** Project changed: ossa => ossn ** Changed in: ossn Status: Incomplete => New ** No longer affects: cinder/grizzly ** No longer affects: cinder/havana ** Changed in: cinder 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/1260679 Title: Multiple drivers set insecure file permissions Status in Cinder: In Progress Status in OpenStack Security Notes: New Bug description: GPFS from various places calls "chmod 666" as root: ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', path, run_as_root=True) ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', vol_path, run_as_root=True) the Huawei driver sets 777 permissions as root on some files: ./cinder/volume/drivers/huawei/ssh_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) ./cinder/volume/drivers/huawei/rest_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) the Scality driver sets 666 permissions on all volumes: cinder/volume/drivers/scality.py:     def _create_file(self, path, size):         with open(path, "ab") as f:             f.truncate(size)         os.chmod(path, 0o666) Similarly, the NFS and NEXENTA driver have an implementation of def _set_rw_permissions_for_all() that is being called on all newly created volumes. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1260679/+subscriptions From thomas at suse.de Mon Feb 10 16:42:08 2014 From: thomas at suse.de (Thomas Biege) Date: Mon, 10 Feb 2014 17:42:08 +0100 Subject: [Openstack-security] eventlet_backdoor.py Message-ID: <52F90160.2040603@suse.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, are there plans to rename the eventlet_backdoor.py module used in the OpenStack code at various places? The naming is bad and creates the impression that a backdoor is in OpenStack. In the current situation it might be an issue the press/blogs are waiting for. Even if renamed the openstack documentation should make it very clear what happens if the admins switches on this option. What do you think? Best, Thomas - -- Thomas Biege , 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.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS+QFgAAoJEJqHoVJVjr8D6wAH/jAtwN9xb90WGArf0V4TyhhR 6yOhm7NBwIelOReG4MoT1MCitrFpGeKkmPAALRPs01SaPgEAdWSnklkv0Hw57cnL GWDozHXZOqKdy0QCyCDMsNm8O1BVrTBCQJUltDgAASKMFj3teoKEdib9iC3i1ZtS yLdiOmuxynE0NCxEC/N7qWODo2/LjkC80G4CLqlIU7MF5EPosKL3qOsERm086cqC UCZmbjQQAIvis6Xoae9JUd+W6qNlabjL6cBIIQCnEbyKPAgekDOdqpq8E/ZdP/8E biAhbZPiQv5tG2/LOydh1GCj5pudngS5zsuDRqDSP16ZiEaECzZF1xb5seD4UuI= =BXHO -----END PGP SIGNATURE----- From kseifried at redhat.com Mon Feb 10 16:46:44 2014 From: kseifried at redhat.com (Kurt Seifried) Date: Mon, 10 Feb 2014 09:46:44 -0700 Subject: [Openstack-security] eventlet_backdoor.py In-Reply-To: <52F90160.2040603@suse.de> References: <52F90160.2040603@suse.de> Message-ID: <52F90274.8060004@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/10/2014 09:42 AM, Thomas Biege wrote: > Hi, are there plans to rename the eventlet_backdoor.py module used > in the OpenStack code at various places? > > The naming is bad and creates the impression that a backdoor is in > OpenStack. In the current situation it might be an issue the > press/blogs are waiting for. > > Even if renamed the openstack documentation should make it very > clear what happens if the admins switches on this option. > > What do you think? > > Best, Thomas +1, this is a rather unfortunate file name, changing it is a good idea. - -- 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 iQIcBAEBAgAGBQJS+QJ0AAoJEBYNRVNeJnmTLasQAMiUKeM/Ql+bks0vMrLz7Ko+ ENI4xWGI5K7e3fHuo422GWgKbIXKcgtcbSU0wskCx6FAvGzrS7zww00HCTblXrol J+aeqTchDSpUfKsjAZxtmyrfEUsIotSk6EVY38W5tk0SYiPt5xwT+CmbYPeZT4S2 XpGV2q3XCibZSUf0Cy3gLeLgRZqxvFFvRJHJcMQeSikAsh0qjjhCabwFcvYDSZ1f 02C1Y5iLxWFMVbRntzcwjwOFrOWLJf0b0e49Js/4aDvsrEVKZqKvlOFD8JfvtdVP 5ueMd1cYq7Ed0ZYP58vBh2/c7luDSWicoBqltUzOiwu2jupSamtdEV3yvPICQE/j 6OtI1VhikMqcdZ4NT2D7onBqyhbcoUutPD4kD0H1hRCq0q1ch+JU9k1xx6TPXlQ5 nzBCnwzUZ0/SuXEdW6zm7gf2VPY43xySH5XsKX8b0z2TFXDl4dw/Yek/QB7rFy33 NKVb+g8Fa3VubMOAP6VXPSKP8J9zqTlhSMgiNwK4yrQuOs0ls0roKyubVHyq2F12 dfNNKc8BCQOu4VVXD0yfwiiWEk1pghw4R4d1jTcN0/Wk3AkwdupXHwsJlwwiWLhx +xR4sldW3KW+rcPxe9f8tHsd9wZ8mIkLSMJF4MA0J0gS1ePk5/9UC4A0aho65nW8 F2t1djTGHO/Cj16C/Jcm =KMxl -----END PGP SIGNATURE----- From berrange at redhat.com Mon Feb 10 16:54:45 2014 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 10 Feb 2014 16:54:45 +0000 Subject: [Openstack-security] eventlet_backdoor.py In-Reply-To: <52F90160.2040603@suse.de> References: <52F90160.2040603@suse.de> Message-ID: <20140210165445.GP2962@redhat.com> On Mon, Feb 10, 2014 at 05:42:08PM +0100, Thomas Biege wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > are there plans to rename the eventlet_backdoor.py module used in the > OpenStack code at various places? > > The naming is bad and creates the impression that a backdoor is in > OpenStack. In the current situation it might be an issue the > press/blogs are waiting for. > > Even if renamed the openstack documentation should make it very clear > what happens if the admins switches on this option. > > What do you think? NB if you enable this feature you basically *have* setup a backdoor into the app for anyone who can connect to the nominated TCP port. So in that sense this is actually accurately named and should serve to discourage any deployers from enabling it without considering the consequences. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From thomas at suse.de Mon Feb 10 17:19:27 2014 From: thomas at suse.de (Thomas Biege) Date: Mon, 10 Feb 2014 18:19:27 +0100 Subject: [Openstack-security] eventlet_backdoor.py In-Reply-To: <20140210165445.GP2962@redhat.com> References: <52F90160.2040603@suse.de> <20140210165445.GP2962@redhat.com> Message-ID: <52F90A1F.30907@suse.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 10.02.2014 17:54, schrieb Daniel P. Berrange: > On Mon, Feb 10, 2014 at 05:42:08PM +0100, Thomas Biege wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Hi, are there plans to rename the eventlet_backdoor.py module >> used in the OpenStack code at various places? >> >> The naming is bad and creates the impression that a backdoor is >> in OpenStack. In the current situation it might be an issue the >> press/blogs are waiting for. >> >> Even if renamed the openstack documentation should make it very >> clear what happens if the admins switches on this option. >> >> What do you think? > > NB if you enable this feature you basically *have* setup a backdoor > into the app for anyone who can connect to the nominated TCP port. > So in that sense this is actually accurately named and should serve > to discourage any deployers from enabling it without considering > the consequences. I am not sure that the name alone creates enough awareness. I also fear that the feature gets switched on, the problem is debugged, and then it will not be turned off again. Like ATMs that eject the money first and then the debit card, which leads to the card being left in the card reader slot because the customer has what he wants, the money. What about removing or restricting the feature? Bye, Thomas > > Daniel > - -- Thomas Biege , 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.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS+QofAAoJEJqHoVJVjr8DLDAH/jN/WSok7tSTHzsGEMiE5kpQ mWtsMr2ByQ2nv4Oo8yI7feXLms8XPYz/rG+CknVkaJ43vm7XNnrWcDMtUJILf2Wk xYAhJeAIVdgOu8bZi8tKgtKUlm30uyZQpppl0dV1cBmqYNsL990tcRSWvxY9nCD0 ZpzGziREIi6Sj9S/pc3XlJ8RaUoe6BhJii0erNQ7E0nOSu/0AGunm6Q+fvM874Yf 6scOcOXzz6zpyVa668mp0jDumlsSZeLjnTxLDXA/WN6H8QM5Rqy2ea9/RGnBfaJ7 6dDaU0dE1GlkfsNZzOOa0xd7cyz4mHte9lKL1+Ekjh0J3lUqLG7NMVpNIGauspo= =4M0m -----END PGP SIGNATURE----- From berrange at redhat.com Mon Feb 10 17:26:28 2014 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 10 Feb 2014 17:26:28 +0000 Subject: [Openstack-security] eventlet_backdoor.py In-Reply-To: <52F90A1F.30907@suse.de> References: <52F90160.2040603@suse.de> <20140210165445.GP2962@redhat.com> <52F90A1F.30907@suse.de> Message-ID: <20140210172628.GS2962@redhat.com> On Mon, Feb 10, 2014 at 06:19:27PM +0100, Thomas Biege wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 10.02.2014 17:54, schrieb Daniel P. Berrange: > > On Mon, Feb 10, 2014 at 05:42:08PM +0100, Thomas Biege wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >> > >> Hi, are there plans to rename the eventlet_backdoor.py module > >> used in the OpenStack code at various places? > >> > >> The naming is bad and creates the impression that a backdoor is > >> in OpenStack. In the current situation it might be an issue the > >> press/blogs are waiting for. > >> > >> Even if renamed the openstack documentation should make it very > >> clear what happens if the admins switches on this option. > >> > >> What do you think? > > > > NB if you enable this feature you basically *have* setup a backdoor > > into the app for anyone who can connect to the nominated TCP port. > > So in that sense this is actually accurately named and should serve > > to discourage any deployers from enabling it without considering > > the consequences. > > I am not sure that the name alone creates enough awareness. I also > fear that the feature gets switched on, the problem is debugged, and > then it will not be turned off again. Like ATMs that eject the money > first and then the debit card, which leads to the card being left in > the card reader slot because the customer has what he wants, the money. > > What about removing or restricting the feature? FYI we have developed a new feature which is intended to replace some of the original uses cases for the backdoor, in a saner manner: https://blueprints.launchpad.net/oslo/+spec/guru-meditation-report This is a feature that will be enabled at all times. An admin merely has to send SIGUSR1 to the process to get it to dump all its interesting state to stderr for troubleshooting. I think this will be far more useful for production environments, and of course safer to since it isn't exposing an arbitrary python shell on an unauthenticated, unencrypted TCP port. Once guru meditation support is merged into all projects, personally I'd have no issue with killing the eventlet backdoor entirely. Others may disagree of course, but it is a conversation worth having IMHO. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From sriram at sriramhere.com Mon Feb 10 19:08:52 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Mon, 10 Feb 2014 11:08:52 -0800 Subject: [Openstack-security] Any Summit pass for OSSG members? Message-ID: Bryan/ Rob/ Nate,, Can OSSG contributing members also get pass for the Summit please? This would help individual contributors like me immensely. Please let me know of your thoughts. -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.clark at hp.com Mon Feb 10 19:10:44 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Mon, 10 Feb 2014 19:10:44 +0000 Subject: [Openstack-security] Any Summit pass for OSSG members? In-Reply-To: References: Message-ID: Not at the moment, though I'd encourage members who feel they have made significant impact to email me a list of their contributions and I'll be happy to petition the organising committee. Cheers -Rob From: Sriram Subramanian [mailto:sriram at sriramhere.com] Sent: 10 February 2014 19:09 To: openstack-security at lists.openstack.org; Bryan Payne; Clark, Robert Graham; Nate Kinder Subject: Any Summit pass for OSSG members? Bryan/ Rob/ Nate,, Can OSSG contributing members also get pass for the Summit please? This would help individual contributors like me immensely. Please let me know of your thoughts. -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From jarret.raim at RACKSPACE.COM Mon Feb 10 19:18:13 2014 From: jarret.raim at RACKSPACE.COM (Jarret Raim) Date: Mon, 10 Feb 2014 19:18:13 +0000 Subject: [Openstack-security] Authentication token generation using UUID In-Reply-To: <6F6793DD-BC97-443E-A0FD-F523CEF4B84D@ericsson.com> References: <6F6793DD-BC97-443E-A0FD-F523CEF4B84D@ericsson.com> Message-ID: I ran this by our team for an opinion on the crypto side of things. Here is their response: "uuid4 is fine. All it does is take 16 bytes of randomness from os.urandom (although a 128-bit uuid4 only encodes 122-bits of randomness since the first 6 bits encode the version of the uuid). Using M2Crypto to generate those random bytes is of little to no value as OpenSSL seeds its CSPRNG from /dev/urandom on POSIX systems anyway (crypto/rand/rand_unix.c if you want to look). To address the statement in RFC 4122: This statement is true for any version of uuid other than uuid4. Since you have 122-bits of RNG state encoded into a uuid4 string you¹d expect an attacker to have 2^(-122) probability of predicting the next token based on the value of the current token received (assuming the underlying RNG is secure, which is a required assumption). (If you had 2^61 simultaneously valid sessions you¹d have a good probability of uuid4() creating the same token twice, but since storing 2^61 128-bit strings requires 3.68934881474191E19 bytes I think we¹re probably safe)" Thanks, Jarret From: Abu Shohel Ahmed Date: Monday, February 10, 2014 at 8:19 AM To: "openstack-security at lists.openstack.org" Subject: [Openstack-security] Authentication token generation using UUID Hi, Currently, Keystone Token provider (both PKI and UUID) relies on uuid.uuid4 to generate token which is used as an authentication token during its lifetime. def _get_token_id(self, token_data): return uuid.uuid4().hex My question is how secure is UUID4 token. According to RFC 4122 "Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access)" The implementation of UUID4 relies on os.urandom() which provides pretty good randomness. However, there are still concerns about its randomness. See the thread here http://stackoverflow.com/questions/817882/unique-session-id-in-python. Should it be a security bug for keystone ? If it is, both PKI and UUID token generation process is vulnerable. ...shohel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5551 bytes Desc: not available URL: From mikal at stillhq.com Mon Feb 10 20:41:02 2014 From: mikal at stillhq.com (Michael Still) Date: Tue, 11 Feb 2014 07:41:02 +1100 Subject: [Openstack-security] Any Summit pass for OSSG members? In-Reply-To: References: Message-ID: The TC has a process to recognise significant non-code contributions from the community. These people can basically be granted ATC status, which would grant a summit ticket discount. I believe the process to apply is for the PTL for your program to email the TC mailing list. Michael On Tue, Feb 11, 2014 at 6:10 AM, Clark, Robert Graham wrote: > Not at the moment, though I'd encourage members who feel they have made > significant impact to email me a list of their contributions and I'll be > happy to petition the organising committee. > > > > Cheers > > -Rob > > > > From: Sriram Subramanian [mailto:sriram at sriramhere.com] > Sent: 10 February 2014 19:09 > To: openstack-security at lists.openstack.org; Bryan Payne; Clark, Robert > Graham; Nate Kinder > Subject: Any Summit pass for OSSG members? > > > > Bryan/ Rob/ Nate,, > > > > Can OSSG contributing members also get pass for the Summit please? This > would help individual contributors like me immensely. > > > > Please let me know of your thoughts. > > > > -- > > Thanks, > > -Sriram > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -- Rackspace Australia From sriram at sriramhere.com Tue Feb 11 00:27:00 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Mon, 10 Feb 2014 16:27:00 -0800 Subject: [Openstack-security] Any Summit pass for OSSG members? In-Reply-To: References: Message-ID: Thanks Michael and Rob. Rob, you were referring to the same effect rt? Thanks! On Mon, Feb 10, 2014 at 12:41 PM, Michael Still wrote: > The TC has a process to recognise significant non-code contributions > from the community. These people can basically be granted ATC status, > which would grant a summit ticket discount. I believe the process to > apply is for the PTL for your program to email the TC mailing list. > > Michael > > On Tue, Feb 11, 2014 at 6:10 AM, Clark, Robert Graham > wrote: > > Not at the moment, though I'd encourage members who feel they have made > > significant impact to email me a list of their contributions and I'll be > > happy to petition the organising committee. > > > > > > > > Cheers > > > > -Rob > > > > > > > > From: Sriram Subramanian [mailto:sriram at sriramhere.com] > > Sent: 10 February 2014 19:09 > > To: openstack-security at lists.openstack.org; Bryan Payne; Clark, Robert > > Graham; Nate Kinder > > Subject: Any Summit pass for OSSG members? > > > > > > > > Bryan/ Rob/ Nate,, > > > > > > > > Can OSSG contributing members also get pass for the Summit please? This > > would help individual contributors like me immensely. > > > > > > > > Please let me know of your thoughts. > > > > > > > > -- > > > > Thanks, > > > > -Sriram > > > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > > > -- > Rackspace Australia > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Tue Feb 11 01:51:12 2014 From: ayoung at redhat.com (Adam Young) Date: Mon, 10 Feb 2014 20:51:12 -0500 Subject: [Openstack-security] Authentication token generation using UUID In-Reply-To: <6F6793DD-BC97-443E-A0FD-F523CEF4B84D@ericsson.com> References: <6F6793DD-BC97-443E-A0FD-F523CEF4B84D@ericsson.com> Message-ID: <52F98210.4000901@redhat.com> On 02/10/2014 09:19 AM, Abu Shohel Ahmed wrote: > Hi, > > Currently, Keystone Token provider (both PKI and UUID) relies on > uuid.uuid4 to generate token which > is used as an authentication token during its lifetime. Not true for PKI tokens, only UUID. PKI tokens are crypto signd (CMS), and then their ID is the MD5 hash of the signed document. And a new format it in the works... > > def _get_token_id(self, token_data): > return uuid.uuid4().hex > > My question is how secure is UUID4 token. According to RFC 4122 > > "Do not assume that UUIDs are hard to guess; they should not be used > as security capabilities (identifiers whose mere possession grants > access)" > > The implementation of UUID4 relies on os.urandom() which provides > pretty good randomness. However, there are still > concerns about its randomness. See the thread here > http://stackoverflow.com/questions/817882/unique-session-id-in-python. > > Should it be a security bug for keystone ? If it is, both PKI and UUID > token generation process is vulnerable. > > ...shohel > > > _______________________________________________ > 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: From thierry at openstack.org Tue Feb 11 10:28:37 2014 From: thierry at openstack.org (Thierry Carrez) Date: Tue, 11 Feb 2014 11:28:37 +0100 Subject: [Openstack-security] Any Summit pass for OSSG members? In-Reply-To: References: Message-ID: <52F9FB55.3000605@openstack.org> Michael Still wrote: > The TC has a process to recognise significant non-code contributions > from the community. These people can basically be granted ATC status, > which would grant a summit ticket discount. I believe the process to > apply is for the PTL for your program to email the TC mailing list. Note that the OSSG by itself is not under a program right now. That said as Release Management PTL I'm willing to consider requests from people working on OSSNs and the "security contacts" that the VMT uses. Anne (Docs PTL) might consider adding key security guide contributors as well. -- Thierry Carrez (ttx) From ahmed.shohel at ericsson.com Tue Feb 11 12:34:13 2014 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Tue, 11 Feb 2014 14:34:13 +0200 Subject: [Openstack-security] Authentication token generation using UUID In-Reply-To: <52F98210.4000901@redhat.com> References: <6F6793DD-BC97-443E-A0FD-F523CEF4B84D@ericsson.com> <52F98210.4000901@redhat.com> Message-ID: <2D8F3D1D-D3D9-4E1D-854D-163D2B8AAB44@ericsson.com> On 11 Feb 2014, at 03:51, Adam Young wrote: > On 02/10/2014 09:19 AM, Abu Shohel Ahmed wrote: >> Hi, >> >> Currently, Keystone Token provider (both PKI and UUID) relies on uuid.uuid4 to generate token which >> is used as an authentication token during its lifetime. > > Not true for PKI tokens, only UUID. PKI tokens are crypto signd (CMS), and then their ID is the MD5 hash of the signed document. > > And a new format it in the works… + true _get_token_id function overriding happens in pki.py >> >> def _get_token_id(self, token_data): >> return uuid.uuid4().hex >> >> My question is how secure is UUID4 token. According to RFC 4122 >> >> "Do not assume that UUIDs are hard to guess; they should not be used >> as security capabilities (identifiers whose mere possession grants >> access)" >> >> The implementation of UUID4 relies on os.urandom() which provides pretty good randomness. However, there are still >> concerns about its randomness. See the thread herehttp://stackoverflow.com/questions/817882/unique-session-id-in-python. >> >> Should it be a security bug for keystone ? If it is, both PKI and UUID token generation process is vulnerable. >> >> ...shohel >> >> >> _______________________________________________ >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4163 bytes Desc: not available URL: From nkinder at redhat.com Tue Feb 11 16:26:24 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 11 Feb 2014 16:26:24 -0000 Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set insecure file permissions References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com> Message-ID: <20140211162625.1966.77731.launchpad@gac.canonical.com> ** Changed in: ossn Assignee: (unassigned) => Nathan Kinder (nkinder) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1260679 Title: Multiple drivers set insecure file permissions Status in Cinder: In Progress Status in OpenStack Security Notes: New Bug description: GPFS from various places calls "chmod 666" as root: ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', path, run_as_root=True) ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', vol_path, run_as_root=True) the Huawei driver sets 777 permissions as root on some files: ./cinder/volume/drivers/huawei/ssh_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) ./cinder/volume/drivers/huawei/rest_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) the Scality driver sets 666 permissions on all volumes: cinder/volume/drivers/scality.py:     def _create_file(self, path, size):         with open(path, "ab") as f:             f.truncate(size)         os.chmod(path, 0o666) Similarly, the NFS and NEXENTA driver have an implementation of def _set_rw_permissions_for_all() that is being called on all newly created volumes. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1260679/+subscriptions From gerrit2 at review.openstack.org Tue Feb 11 19:51:47 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 11 Feb 2014 19:51:47 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/70228 Log: commit d4079d82544f2db3847688dcc5cfb82034dba07b Author: Kaitlin Farr Date: Mon Feb 3 12:16:51 2014 -0500 Adds ephemeral storage encryption for Raw back-end images This patch adds ephemeral storage encryption for Raw back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue is not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Change-Id: I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Implements: blueprint encrypt-ephemeral-storage DocImpact SecurityImpact From gerrit2 at review.openstack.org Wed Feb 12 12:30:02 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 12 Feb 2014 12:30:02 +0000 Subject: [Openstack-security] [openstack/python-swiftclient] SecurityImpact review request change Ib5de962f4102d57c71ad85fd81a615362ef175dc Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/69187 Log: commit b182112719ab87942472e44aa3446ea0eb19a289 Author: Tristan Cacqueray Date: Fri Jan 24 17:40:16 2014 +0100 Port to python-requests Currently, httplib implementation does not support SSL certificate verification. This patch fixes this. Note that ssl compression parameter and 100-continue thing is still missing from requests, though those are lower priority. Requests now takes care of: * proxy configuration (get_environ_proxies), * chunked encoding (with data generator), * bulk uploading (with files dictionary), * SSL certificate verification (with 'insecure' and 'cacert' parameter). This patch have been tested with requests 1.1.0 (CentOS 6) and requests 2.2.1 (current version). Change-Id: Ib5de962f4102d57c71ad85fd81a615362ef175dc Closes-Bug: #1199783 DocImpact SecurityImpact From malini.k.bhandaru at intel.com Thu Feb 13 08:47:31 2014 From: malini.k.bhandaru at intel.com (Malini Bhandaru) Date: Thu, 13 Feb 2014 08:47:31 -0000 Subject: [Openstack-security] [Bug 1243534] Re: contradiction on default cryptography ciphers References: <20131023060123.12728.63393.malonedeb@gac.canonical.com> Message-ID: <20140213084731.2013.76126.malone@soybean.canonical.com> Thank you Jeffrey! I added the text and new config string. Please take a look at: https://review.openstack.org/73195 ** Changed in: openstack-manuals Assignee: OpenStack Security Group (openstack-ossg) => Malini Bhandaru (malini-k-bhandaru) -- You received this bug notification because you are a member of OpenStack Security Group, which is a bug assignee. https://bugs.launchpad.net/bugs/1243534 Title: contradiction on default cryptography ciphers Status in OpenStack Manuals: Confirmed Bug description: Chapter 13: 'As this book does not intend to be a thorough reference on cryptography we do not wish to be prescriptive about what specific algorithms or cipher modes you should enable or disable in your OpenStack services.' Chapter 15: 'ciphers = "HIGH:!aNULL:!eNULL:!DES:!3DES"' ----------------------------------- Built: 2013-10-22T21:22:10 00:00 git SHA: 72ee6fa1cfcd6a1ae2d86d78a6ac3f8709f5aaf4 URL: http://docs.openstack.org/security-guide/content/ch017_threat-models-confidence-and-confidentiality.html source File: file:/home/jenkins/workspace/openstack-security-guide/doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml xml:id: ch017_threat-models-confidence-and-confidentiality To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-manuals/+bug/1243534/+subscriptions From thomas at suse.de Thu Feb 13 09:18:53 2014 From: thomas at suse.de (Thomas Biege) Date: Thu, 13 Feb 2014 10:18:53 +0100 Subject: [Openstack-security] eventlet_backdoor.py In-Reply-To: <20140210172628.GS2962@redhat.com> References: <52F90160.2040603@suse.de> <20140210165445.GP2962@redhat.com> <52F90A1F.30907@suse.de> <20140210172628.GS2962@redhat.com> Message-ID: <52FC8DFD.1060004@suse.de> Am 10.02.14 18:26, schrieb Daniel P. Berrange: > On Mon, Feb 10, 2014 at 06:19:27PM +0100, Thomas Biege wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am 10.02.2014 17:54, schrieb Daniel P. Berrange: >>> On Mon, Feb 10, 2014 at 05:42:08PM +0100, Thomas Biege wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> Hi, are there plans to rename the eventlet_backdoor.py module >>>> used in the OpenStack code at various places? >>>> >>>> The naming is bad and creates the impression that a backdoor is >>>> in OpenStack. In the current situation it might be an issue the >>>> press/blogs are waiting for. >>>> >>>> Even if renamed the openstack documentation should make it very >>>> clear what happens if the admins switches on this option. >>>> >>>> What do you think? >>> >>> NB if you enable this feature you basically *have* setup a backdoor >>> into the app for anyone who can connect to the nominated TCP port. >>> So in that sense this is actually accurately named and should serve >>> to discourage any deployers from enabling it without considering >>> the consequences. >> >> I am not sure that the name alone creates enough awareness. I also >> fear that the feature gets switched on, the problem is debugged, and >> then it will not be turned off again. Like ATMs that eject the money >> first and then the debit card, which leads to the card being left in >> the card reader slot because the customer has what he wants, the money. >> >> What about removing or restricting the feature? > > FYI we have developed a new feature which is intended to replace > some of the original uses cases for the backdoor, in a saner > manner: > > https://blueprints.launchpad.net/oslo/+spec/guru-meditation-report > > This is a feature that will be enabled at all times. An admin merely > has to send SIGUSR1 to the process to get it to dump all its interesting > state to stderr for troubleshooting. I think this will be far more useful > for production environments, and of course safer to since it isn't > exposing an arbitrary python shell on an unauthenticated, unencrypted > TCP port. Yes, this feature looks really important, not only because it removes the backdoor issue. Best, Thomas > > Once guru meditation support is merged into all projects, personally > I'd have no issue with killing the eventlet backdoor entirely. Others > may disagree of course, but it is a conversation worth having IMHO. > > Daniel > -- Thomas Biege , 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 560 bytes Desc: OpenPGP digital signature URL: From thierry.carrez+lp at gmail.com Thu Feb 13 17:21:57 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 13 Feb 2014 17:21:57 -0000 Subject: [Openstack-security] [Bug 1279849] Re: keystone password creation and verification mismatch References: <20140213153829.1383.20321.malonedeb@chaenomeles.canonical.com> Message-ID: <20140213172157.1966.86121.launchpad@gac.canonical.com> ** Information type changed from Public Security to Public ** 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/1279849 Title: keystone password creation and verification mismatch Status in OpenStack Identity (Keystone): New Bug description: In keystone stable/Havana release, password for a user can be set during user creation process. Now if a user initially do a sha512 hash of his password and sent it to the keystone server over the wire, then hash_password method of keystone/common/utils.py def hash_password(password): ~ | """Hash a password. Hard.""" ~ | password_utf8 = trunc_password(password).encode('utf-8') ~ | if passlib.hash.sha512_crypt.identify(password_utf8): ~ | return password_utf8 ~ | h = passlib.hash.sha512_crypt.encrypt(password_utf8, ~ | rounds=CONF.crypt_strength) ~ | return h will not do any hashing, or it directly store the password in DB. However, during authentication, the user needs to provide the clear text password for authentication because during authentication it always does sha512 over the password field (it does not check the password is already hashed) def check_password(password, hashed): ""Check that a plaintext password matches hashed. hashpw returns the salt value concatenated with the actual hash value. It extracts the actual salt if this value is then passed as the salt. """ if password is None or hashed is None: return False password_utf8 = trunc_password(password).encode('utf-8') return passlib.hash.sha512_crypt.verify(password_utf8, hashed) Now in this case, 1) user chooses a password which is similar to a sha512 output, now keystone thinks it is already hashed, so it will store it as it is. User provides the sha512 during authentication but he cannot login this time cause now the password is hashed before matching. There should be consistency for both password creation and verification process. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1279849/+subscriptions From nkinder at redhat.com Thu Feb 13 18:05:14 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 13 Feb 2014 18:05:14 -0000 Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set insecure file permissions References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com> Message-ID: <20140213180517.1826.13409.launchpad@soybean.canonical.com> ** Changed in: ossn Status: New => 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/1260679 Title: Multiple drivers set insecure file permissions Status in Cinder: In Progress Status in OpenStack Security Notes: In Progress Bug description: GPFS from various places calls "chmod 666" as root: ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', path, run_as_root=True) ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', vol_path, run_as_root=True) the Huawei driver sets 777 permissions as root on some files: ./cinder/volume/drivers/huawei/ssh_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) ./cinder/volume/drivers/huawei/rest_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) the Scality driver sets 666 permissions on all volumes: cinder/volume/drivers/scality.py:     def _create_file(self, path, size):         with open(path, "ab") as f:             f.truncate(size)         os.chmod(path, 0o666) Similarly, the NFS and NEXENTA driver have an implementation of def _set_rw_permissions_for_all() that is being called on all newly created volumes. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1260679/+subscriptions From gerrit2 at review.openstack.org Fri Feb 14 00:41:52 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 14 Feb 2014 00:41:52 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change Ic01d91c0d660c74095e8d2b212279b39b9b9dc05 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/73112 Log: commit b0ac8294dd9d8dbddfbb320c62d7264daf55be26 Author: Bill Owen Date: Wed Feb 12 17:37:36 2014 -0700 Update gpfs driver volume creation process Modify gpfs driver to set file permissions in a more consistent way. Modify image_utils.resize_image to allow caller to request it be run as root. SecurityImpact Change-Id: Ic01d91c0d660c74095e8d2b212279b39b9b9dc05 Partial-Bug: #1260679 From sriram at sriramhere.com Fri Feb 14 04:08:46 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Thu, 13 Feb 2014 20:08:46 -0800 Subject: [Openstack-security] Fuzzy test framework in Tempest In-Reply-To: References: Message-ID: Bryan/ Marc, Apologies I missed the OSSG meeting. Looks like this was discussed last week, but I didn't see any action items or updates in the logs. Could one of you update please? thanks, -Sriram On Wed, Feb 5, 2014 at 9:57 AM, Bryan D. Payne wrote: > Marc, > > This is certainly of interest to OSSG. There were some people talking > about doing security testing before the last summit, but I haven't heard > much about that recently. Please do join us for the meeting tomorrow and > we can discuss in some more detail. I'll see if I can encourage the other > parties to participate as well. > > Cheers, > -bryan > > > > > On Wed, Feb 5, 2014 at 6:54 AM, Koderer, Marc wrote: > >> Hello Security Team, >> >> David and I are currently working on an automated framework for negative >> testing in Tempest. This frameworks generates tests out of json schema >> definitions (see https://review.openstack.org/#/c/64733/ and >> https://blueprints.launchpad.net/tempest/+spec/negative-tests). >> >> During discussion we came to the idea that it would be quite easy to >> build a >> security fuzzy test framework out of existing pieces in Tempest. If we'd >> run >> the negative tests in our stress test framework that launches a certain >> number >> of concurrent worker processes. At the end of a run we could use Tempest >> again >> to validate that all services are up and running. >> >> Is this topic potentially interesting for this group? >> I saw on your launchpad task board that your are planning something >> similar: >> "Develop stress tests that can be integrated with current testing" >> Did somebody already spend some effort in that area? >> >> I'd like to join your meeting tomorrow and discuss about it. >> >> Regards >> Marc >> >> DEUTSCHE TELEKOM AG >> Digital Business Unit, Cloud Services (P&I) >> Marc Koderer >> Cloud Technology Software Developer >> T-Online-Allee 1, 64211 Darmstadt >> E-Mail: m.koderer at telekom.de >> www.telekom.com >> >> LIFE IS FOR SHARING. >> >> DEUTSCHE TELEKOM AG >> Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) >> Board of Management: René Obermann (Chairman), >> Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, >> Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick >> Commercial register: Amtsgericht Bonn HRB 6794 >> Registered office: Bonn >> >> BIG CHANGES START SMALL - CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. >> _______________________________________________ >> 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 > > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdpayne at acm.org Fri Feb 14 05:35:37 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Thu, 13 Feb 2014 21:35:37 -0800 Subject: [Openstack-security] Fuzzy test framework in Tempest In-Reply-To: References: Message-ID: We left it with Marc needing to take the next step, which will be to put together a blueprint for this. Once he has that in place, he'll let OSSG know and we can help him drive it forward. Marc, please let us know if I missed something. Cheers, -bryan On Thu, Feb 13, 2014 at 8:08 PM, Sriram Subramanian wrote: > Bryan/ Marc, > > Apologies I missed the OSSG meeting. Looks like this was discussed last > week, but I didn't see any action items or updates in the logs. Could one > of you update please? > > thanks, > -Sriram > > > On Wed, Feb 5, 2014 at 9:57 AM, Bryan D. Payne wrote: > >> Marc, >> >> This is certainly of interest to OSSG. There were some people talking >> about doing security testing before the last summit, but I haven't heard >> much about that recently. Please do join us for the meeting tomorrow and >> we can discuss in some more detail. I'll see if I can encourage the other >> parties to participate as well. >> >> Cheers, >> -bryan >> >> >> >> >> On Wed, Feb 5, 2014 at 6:54 AM, Koderer, Marc wrote: >> >>> Hello Security Team, >>> >>> David and I are currently working on an automated framework for negative >>> testing in Tempest. This frameworks generates tests out of json schema >>> definitions (see https://review.openstack.org/#/c/64733/ and >>> https://blueprints.launchpad.net/tempest/+spec/negative-tests). >>> >>> During discussion we came to the idea that it would be quite easy to >>> build a >>> security fuzzy test framework out of existing pieces in Tempest. If we'd >>> run >>> the negative tests in our stress test framework that launches a certain >>> number >>> of concurrent worker processes. At the end of a run we could use Tempest >>> again >>> to validate that all services are up and running. >>> >>> Is this topic potentially interesting for this group? >>> I saw on your launchpad task board that your are planning something >>> similar: >>> "Develop stress tests that can be integrated with current testing" >>> Did somebody already spend some effort in that area? >>> >>> I'd like to join your meeting tomorrow and discuss about it. >>> >>> Regards >>> Marc >>> >>> DEUTSCHE TELEKOM AG >>> Digital Business Unit, Cloud Services (P&I) >>> Marc Koderer >>> Cloud Technology Software Developer >>> T-Online-Allee 1, 64211 Darmstadt >>> E-Mail: m.koderer at telekom.de >>> www.telekom.com >>> >>> LIFE IS FOR SHARING. >>> >>> DEUTSCHE TELEKOM AG >>> Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) >>> Board of Management: René Obermann (Chairman), >>> Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, >>> Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick >>> Commercial register: Amtsgericht Bonn HRB 6794 >>> Registered office: Bonn >>> >>> BIG CHANGES START SMALL - CONSERVE RESOURCES BY NOT PRINTING EVERY >>> E-MAIL. >>> _______________________________________________ >>> 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 >> >> > > > -- > Thanks, > -Sriram > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sriram at sriramhere.com Fri Feb 14 07:43:19 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Thu, 13 Feb 2014 23:43:19 -0800 Subject: [Openstack-security] Fuzzy test framework in Tempest In-Reply-To: References: Message-ID: Thanks Bryan! On Thu, Feb 13, 2014 at 9:35 PM, Bryan D. Payne wrote: > We left it with Marc needing to take the next step, which will be to put > together a blueprint for this. Once he has that in place, he'll let OSSG > know and we can help him drive it forward. > > Marc, please let us know if I missed something. > > Cheers, > -bryan > > > > On Thu, Feb 13, 2014 at 8:08 PM, Sriram Subramanian > wrote: > >> Bryan/ Marc, >> >> Apologies I missed the OSSG meeting. Looks like this was discussed last >> week, but I didn't see any action items or updates in the logs. Could one >> of you update please? >> >> thanks, >> -Sriram >> >> >> On Wed, Feb 5, 2014 at 9:57 AM, Bryan D. Payne wrote: >> >>> Marc, >>> >>> This is certainly of interest to OSSG. There were some people talking >>> about doing security testing before the last summit, but I haven't heard >>> much about that recently. Please do join us for the meeting tomorrow and >>> we can discuss in some more detail. I'll see if I can encourage the other >>> parties to participate as well. >>> >>> Cheers, >>> -bryan >>> >>> >>> >>> >>> On Wed, Feb 5, 2014 at 6:54 AM, Koderer, Marc wrote: >>> >>>> Hello Security Team, >>>> >>>> David and I are currently working on an automated framework for negative >>>> testing in Tempest. This frameworks generates tests out of json schema >>>> definitions (see https://review.openstack.org/#/c/64733/ and >>>> https://blueprints.launchpad.net/tempest/+spec/negative-tests). >>>> >>>> During discussion we came to the idea that it would be quite easy to >>>> build a >>>> security fuzzy test framework out of existing pieces in Tempest. If >>>> we'd run >>>> the negative tests in our stress test framework that launches a certain >>>> number >>>> of concurrent worker processes. At the end of a run we could use >>>> Tempest again >>>> to validate that all services are up and running. >>>> >>>> Is this topic potentially interesting for this group? >>>> I saw on your launchpad task board that your are planning something >>>> similar: >>>> "Develop stress tests that can be integrated with current testing" >>>> Did somebody already spend some effort in that area? >>>> >>>> I'd like to join your meeting tomorrow and discuss about it. >>>> >>>> Regards >>>> Marc >>>> >>>> DEUTSCHE TELEKOM AG >>>> Digital Business Unit, Cloud Services (P&I) >>>> Marc Koderer >>>> Cloud Technology Software Developer >>>> T-Online-Allee 1, 64211 Darmstadt >>>> E-Mail: m.koderer at telekom.de >>>> www.telekom.com >>>> >>>> LIFE IS FOR SHARING. >>>> >>>> DEUTSCHE TELEKOM AG >>>> Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) >>>> Board of Management: René Obermann (Chairman), >>>> Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, >>>> Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick >>>> Commercial register: Amtsgericht Bonn HRB 6794 >>>> Registered office: Bonn >>>> >>>> BIG CHANGES START SMALL - CONSERVE RESOURCES BY NOT PRINTING EVERY >>>> E-MAIL. >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> Thanks, >> -Sriram >> > > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From sriram at sriramhere.com Fri Feb 14 07:51:04 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Thu, 13 Feb 2014 23:51:04 -0800 Subject: [Openstack-security] Fuzzy test framework in Tempest In-Reply-To: References: Message-ID: FYI: I felt fuzzing could be an interesting project for GSoC, so proposed it as one of the project ideas. I am not sure how many of those projects would get selected; in case it gets selected, hey, we get an intern! Marc - would look for your bp! Thanks! On Thu, Feb 13, 2014 at 11:43 PM, Sriram Subramanian wrote: > Thanks Bryan! > > > On Thu, Feb 13, 2014 at 9:35 PM, Bryan D. Payne wrote: > >> We left it with Marc needing to take the next step, which will be to put >> together a blueprint for this. Once he has that in place, he'll let OSSG >> know and we can help him drive it forward. >> >> Marc, please let us know if I missed something. >> >> Cheers, >> -bryan >> >> >> >> On Thu, Feb 13, 2014 at 8:08 PM, Sriram Subramanian < >> sriram at sriramhere.com> wrote: >> >>> Bryan/ Marc, >>> >>> Apologies I missed the OSSG meeting. Looks like this was discussed last >>> week, but I didn't see any action items or updates in the logs. Could one >>> of you update please? >>> >>> thanks, >>> -Sriram >>> >>> >>> On Wed, Feb 5, 2014 at 9:57 AM, Bryan D. Payne wrote: >>> >>>> Marc, >>>> >>>> This is certainly of interest to OSSG. There were some people talking >>>> about doing security testing before the last summit, but I haven't heard >>>> much about that recently. Please do join us for the meeting tomorrow and >>>> we can discuss in some more detail. I'll see if I can encourage the other >>>> parties to participate as well. >>>> >>>> Cheers, >>>> -bryan >>>> >>>> >>>> >>>> >>>> On Wed, Feb 5, 2014 at 6:54 AM, Koderer, Marc wrote: >>>> >>>>> Hello Security Team, >>>>> >>>>> David and I are currently working on an automated framework for >>>>> negative >>>>> testing in Tempest. This frameworks generates tests out of json schema >>>>> definitions (see https://review.openstack.org/#/c/64733/ and >>>>> https://blueprints.launchpad.net/tempest/+spec/negative-tests). >>>>> >>>>> During discussion we came to the idea that it would be quite easy to >>>>> build a >>>>> security fuzzy test framework out of existing pieces in Tempest. If >>>>> we'd run >>>>> the negative tests in our stress test framework that launches a >>>>> certain number >>>>> of concurrent worker processes. At the end of a run we could use >>>>> Tempest again >>>>> to validate that all services are up and running. >>>>> >>>>> Is this topic potentially interesting for this group? >>>>> I saw on your launchpad task board that your are planning something >>>>> similar: >>>>> "Develop stress tests that can be integrated with current testing" >>>>> Did somebody already spend some effort in that area? >>>>> >>>>> I'd like to join your meeting tomorrow and discuss about it. >>>>> >>>>> Regards >>>>> Marc >>>>> >>>>> DEUTSCHE TELEKOM AG >>>>> Digital Business Unit, Cloud Services (P&I) >>>>> Marc Koderer >>>>> Cloud Technology Software Developer >>>>> T-Online-Allee 1, 64211 Darmstadt >>>>> E-Mail: m.koderer at telekom.de >>>>> www.telekom.com >>>>> >>>>> LIFE IS FOR SHARING. >>>>> >>>>> DEUTSCHE TELEKOM AG >>>>> Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) >>>>> Board of Management: René Obermann (Chairman), >>>>> Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, >>>>> Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick >>>>> Commercial register: Amtsgericht Bonn HRB 6794 >>>>> Registered office: Bonn >>>>> >>>>> BIG CHANGES START SMALL - CONSERVE RESOURCES BY NOT PRINTING EVERY >>>>> E-MAIL. >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> Thanks, >>> -Sriram >>> >> >> > > > -- > Thanks, > -Sriram > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.koderer at telekom.de Fri Feb 14 08:29:50 2014 From: m.koderer at telekom.de (Koderer, Marc) Date: Fri, 14 Feb 2014 09:29:50 +0100 Subject: [Openstack-security] Fuzzy test framework in Tempest In-Reply-To: References: Message-ID: Hi folks, I wanted to discuss the blueprint in the QA meeting before opening it. Here it is: https://blueprints.launchpad.net/tempest/+spec/fuzzy-test I will collect work items in Etherpad during the day: https://etherpad.openstack.org/p/bp_fuzzy_test GSoC sound awesome, pls keep me updated on that. Don't hesitate to contact me directly on IRC (freenode / mkoderer) I am already working on the first patch that allows multiple record generators. My plan is to allow make it configurable whether it's simply a random generator or a pattern based generator. Regards Marc Von: Sriram Subramanian [mailto:sriram at sriramhere.com] Gesendet: Freitag, 14. Februar 2014 08:51 An: Bryan D. Payne Cc: Koderer, Marc; openstack-security at lists.openstack.org; dkranz at redhat.com Betreff: Re: [Openstack-security] Fuzzy test framework in Tempest FYI: I felt fuzzing could be an interesting project for GSoC, so proposed it as one of the project ideas. I am not sure how many of those projects would get selected; in case it gets selected, hey, we get an intern! Marc - would look for your bp! Thanks! On Thu, Feb 13, 2014 at 11:43 PM, Sriram Subramanian > wrote: Thanks Bryan! On Thu, Feb 13, 2014 at 9:35 PM, Bryan D. Payne > wrote: We left it with Marc needing to take the next step, which will be to put together a blueprint for this. Once he has that in place, he'll let OSSG know and we can help him drive it forward. Marc, please let us know if I missed something. Cheers, -bryan On Thu, Feb 13, 2014 at 8:08 PM, Sriram Subramanian > wrote: Bryan/ Marc, Apologies I missed the OSSG meeting. Looks like this was discussed last week, but I didn't see any action items or updates in the logs. Could one of you update please? thanks, -Sriram On Wed, Feb 5, 2014 at 9:57 AM, Bryan D. Payne > wrote: Marc, This is certainly of interest to OSSG. There were some people talking about doing security testing before the last summit, but I haven't heard much about that recently. Please do join us for the meeting tomorrow and we can discuss in some more detail. I'll see if I can encourage the other parties to participate as well. Cheers, -bryan On Wed, Feb 5, 2014 at 6:54 AM, Koderer, Marc > wrote: Hello Security Team, David and I are currently working on an automated framework for negative testing in Tempest. This frameworks generates tests out of json schema definitions (see https://review.openstack.org/#/c/64733/ and https://blueprints.launchpad.net/tempest/+spec/negative-tests). During discussion we came to the idea that it would be quite easy to build a security fuzzy test framework out of existing pieces in Tempest. If we'd run the negative tests in our stress test framework that launches a certain number of concurrent worker processes. At the end of a run we could use Tempest again to validate that all services are up and running. Is this topic potentially interesting for this group? I saw on your launchpad task board that your are planning something similar: "Develop stress tests that can be integrated with current testing" Did somebody already spend some effort in that area? I'd like to join your meeting tomorrow and discuss about it. Regards Marc DEUTSCHE TELEKOM AG Digital Business Unit, Cloud Services (P&I) Marc Koderer Cloud Technology Software Developer T-Online-Allee 1, 64211 Darmstadt E-Mail: m.koderer at telekom.de www.telekom.com LIFE IS FOR SHARING. DEUTSCHE TELEKOM AG Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) Board of Management: René Obermann (Chairman), Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick Commercial register: Amtsgericht Bonn HRB 6794 Registered office: Bonn BIG CHANGES START SMALL - CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. _______________________________________________ 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 -- Thanks, -Sriram -- Thanks, -Sriram -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From sriram at sriramhere.com Fri Feb 14 08:38:06 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Fri, 14 Feb 2014 00:38:06 -0800 Subject: [Openstack-security] Fuzzy test framework in Tempest In-Reply-To: References: Message-ID: Thanks Marc, great start! Pattern based generator might be more effective than random, but having it configurable is great. Thanks! On Fri, Feb 14, 2014 at 12:29 AM, Koderer, Marc wrote: > Hi folks, > > > > I wanted to discuss the blueprint in the QA meeting before opening it. > > > > Here it is: > > > > https://blueprints.launchpad.net/tempest/+spec/fuzzy-test > > > > I will collect work items in Etherpad during the day: > > https://etherpad.openstack.org/p/bp_fuzzy_test > > > > GSoC sound awesome, pls keep me updated on that. > > Don't hesitate to contact me directly on IRC (freenode / mkoderer) > > > > I am already working on the first patch that allows multiple record > generators. My plan is to allow make it configurable whether it's simply a > random generator or a pattern based generator. > > > > Regards > > Marc > > > > > > *Von:* Sriram Subramanian [mailto:sriram at sriramhere.com] > *Gesendet:* Freitag, 14. Februar 2014 08:51 > *An:* Bryan D. Payne > *Cc:* Koderer, Marc; openstack-security at lists.openstack.org; > dkranz at redhat.com > *Betreff:* Re: [Openstack-security] Fuzzy test framework in Tempest > > > > FYI: I felt fuzzing could be an interesting project for GSoC, > so proposed it as one of the project ideas. I am not sure how many of those > projects would get selected; in case it gets selected, hey, we get an > intern! > > > > Marc - would look for your bp! > > > > Thanks! > > > > On Thu, Feb 13, 2014 at 11:43 PM, Sriram Subramanian < > sriram at sriramhere.com> wrote: > > Thanks Bryan! > > > > On Thu, Feb 13, 2014 at 9:35 PM, Bryan D. Payne wrote: > > We left it with Marc needing to take the next step, which will be to put > together a blueprint for this. Once he has that in place, he'll let OSSG > know and we can help him drive it forward. > > > > Marc, please let us know if I missed something. > > > > Cheers, > > -bryan > > > > > > On Thu, Feb 13, 2014 at 8:08 PM, Sriram Subramanian > wrote: > > Bryan/ Marc, > > > > Apologies I missed the OSSG meeting. Looks like this was discussed last > week, but I didn't see any action items or updates in the logs. Could one > of you update please? > > > > thanks, > > -Sriram > > > > On Wed, Feb 5, 2014 at 9:57 AM, Bryan D. Payne wrote: > > Marc, > > > > This is certainly of interest to OSSG. There were some people talking > about doing security testing before the last summit, but I haven't heard > much about that recently. Please do join us for the meeting tomorrow and > we can discuss in some more detail. I'll see if I can encourage the other > parties to participate as well. > > > > Cheers, > > -bryan > > > > > > > > On Wed, Feb 5, 2014 at 6:54 AM, Koderer, Marc > wrote: > > Hello Security Team, > > David and I are currently working on an automated framework for negative > testing in Tempest. This frameworks generates tests out of json schema > definitions (see https://review.openstack.org/#/c/64733/ and > https://blueprints.launchpad.net/tempest/+spec/negative-tests). > > During discussion we came to the idea that it would be quite easy to build > a > security fuzzy test framework out of existing pieces in Tempest. If we'd > run > the negative tests in our stress test framework that launches a certain > number > of concurrent worker processes. At the end of a run we could use Tempest > again > to validate that all services are up and running. > > Is this topic potentially interesting for this group? > I saw on your launchpad task board that your are planning something > similar: > "Develop stress tests that can be integrated with current testing" > Did somebody already spend some effort in that area? > > I'd like to join your meeting tomorrow and discuss about it. > > Regards > Marc > > DEUTSCHE TELEKOM AG > Digital Business Unit, Cloud Services (P&I) > Marc Koderer > Cloud Technology Software Developer > T-Online-Allee 1, 64211 Darmstadt > E-Mail: m.koderer at telekom.de > www.telekom.com > > LIFE IS FOR SHARING. > > DEUTSCHE TELEKOM AG > Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) > Board of Management: René Obermann (Chairman), > Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, > Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick > Commercial register: Amtsgericht Bonn HRB 6794 > Registered office: Bonn > > BIG CHANGES START SMALL - CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. > _______________________________________________ > 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 > > > > > > -- > > Thanks, > > -Sriram > > > > > > > > -- > > Thanks, > > -Sriram > > > > > > -- > > Thanks, > > -Sriram > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerrit2 at review.openstack.org Fri Feb 14 19:42:20 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 14 Feb 2014 19:42:20 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit cec40062c938fb7dab070642b26fdf93df1507df Author: Dan Genin Date: Thu Jan 2 09:45:11 2014 -0500 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From damon.devops at gmail.com Tue Feb 4 03:04:44 2014 From: damon.devops at gmail.com (Wei Wang) Date: Tue, 04 Feb 2014 03:04:44 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140204030444.1859.69608.malone@soybean.canonical.com> Numero 8's patch almost resolve this bug, maybe I can continue it. ** Changed in: python-keystoneclient Assignee: (unassigned) => Wei Wang (damon-devops) -- 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 chungg at linux.vnet.ibm.com Tue Feb 4 21:10:21 2014 From: chungg at linux.vnet.ibm.com (gordon chung) Date: Tue, 04 Feb 2014 21:10:21 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140204211021.2091.16805.malone@chaenomeles.canonical.com> might make sense to just pull/copy mask_password code from oslo- incubator log.py to mask password... worked for me. -- 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 dpyzhov at mirantis.com Wed Feb 5 13:54:04 2014 From: dpyzhov at mirantis.com (Dmitry Pyzhov) Date: Wed, 05 Feb 2014 13:54:04 -0000 Subject: [Openstack-security] [Bug 1272349] Re: We shouldn't assign public addresses for computes, ceph-osd and cinder-lvm roles References: <20140124141418.15657.35524.malonedeb@gac.canonical.com> Message-ID: <20140205135406.1830.48377.launchpad@chaenomeles.canonical.com> ** Changed in: fuel Milestone: None => 5.0 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1272349 Title: We shouldn't assign public addresses for computes, ceph-osd and cinder-lvm roles Status in Fuel: OpenStack installer that works: Triaged Bug description: Fuel assigns public network to all nodes in the cloud. But, in fact, only controller nodes should have a public network. We should remove public network for roles: - computes - ceph-osd - cinder-lvm Exception: in case nova-network (multi host) computes required public network. To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1272349/+subscriptions From 1246160 at bugs.launchpad.net Fri Feb 7 18:16:52 2014 From: 1246160 at bugs.launchpad.net (Russell Bryant) Date: Fri, 07 Feb 2014 18:16:52 -0000 Subject: [Openstack-security] [Bug 1246160] Re: shuffle method bring potential security issue References: <20131030014106.17323.98896.malonedeb@chaenomeles.canonical.com> Message-ID: <20140207181656.1631.99697.launchpad@soybean.canonical.com> ** Changed in: nova Importance: Undecided => Wishlist ** Changed in: nova Status: New => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1246160 Title: shuffle method bring potential security issue Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Invalid Bug description: In the /nova/utils.py, line 328, the source code is below r.shuffle(password) This code is using shuffle method to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1246160/+subscriptions From 1246159 at bugs.launchpad.net Fri Feb 7 18:15:49 2014 From: 1246159 at bugs.launchpad.net (Russell Bryant) Date: Fri, 07 Feb 2014 18:15:49 -0000 Subject: [Openstack-security] [Bug 1246159] Re: seed method brings potential security issue References: <20131030013717.19024.324.malonedeb@gac.canonical.com> Message-ID: <20140207181549.1698.80210.malone@wampee.canonical.com> marked as invalid for nova, as this is talking about cinder code ** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1246159 Title: seed method brings potential security issue Status in OpenStack Compute (Nova): Invalid Status in OpenStack Security Advisories: Invalid Bug description: In the /cinder/transfer/apil.py, line 86, the source code is below random.seed(datetime.datetime.now().microsecond) This code is using seed method to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1246159/+subscriptions From 1246158 at bugs.launchpad.net Fri Feb 7 18:16:01 2014 From: 1246158 at bugs.launchpad.net (Russell Bryant) Date: Fri, 07 Feb 2014 18:16:01 -0000 Subject: [Openstack-security] [Bug 1246158] Re: randint method brings potential security issue References: <20131030013205.19024.89786.malonedeb@gac.canonical.com> Message-ID: <20140207181601.2013.16987.malone@soybean.canonical.com> marked invalid for nova as this is talking about keystone code ** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1246158 Title: randint method brings potential security issue Status in OpenStack Compute (Nova): Invalid Status in OpenStack Security Advisories: Invalid Bug description: In the /keystone/contrib/oauth1/backends/sql.py, line 210, the source code is below token_dict['verifier'] = str(random.randint(1000, 9999)) This code is using randint method to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1246158/+subscriptions From 1081795 at bugs.launchpad.net Sat Feb 8 15:50:32 2014 From: 1081795 at bugs.launchpad.net (Dirk Mueller) Date: Sat, 08 Feb 2014 15:50:32 -0000 Subject: [Openstack-security] [Bug 1081795] Re: oslo.rootwrap IpFilter fails to prevent ip netns exec References: <20121121214352.19413.92008.malonedeb@wampee.canonical.com> Message-ID: <20140208155033.1383.94681.launchpad@chaenomeles.canonical.com> ** Changed in: oslo Assignee: (unassigned) => Dirk Mueller (dmllr) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1081795 Title: oslo.rootwrap IpFilter fails to prevent ip netns exec Status in Oslo - a Library of Common OpenStack Code: Triaged Bug description: This is an oslo.rootwrap bug. IpFilter is designed to allow any ip command, unless the second parameter is "netns" (in which case you only allow ip netns {list,add,delete}. The trick is it's trivial to work around this (just run 'ip -s netns exec'). Once that's fixed, Nova should update from using a CommandFilter to using the IpFilter for calling 'ip'. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1081795/+subscriptions From 1262759 at bugs.launchpad.net Mon Feb 10 03:35:51 2014 From: 1262759 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 10 Feb 2014 03:35:51 -0000 Subject: [Openstack-security] [Bug 1262759] Re: ICMPv6 RAs should only be permitted from known routers References: <20131219170628.26400.87374.malonedeb@chaenomeles.canonical.com> Message-ID: <20140210033551.2216.46033.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/72252 ** Changed in: neutron Status: New => 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/1262759 Title: ICMPv6 RAs should only be permitted from known routers Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Advisories: Invalid Bug description: ICMPv6 is now allowed in from any host but other hosts can offer bogus routes. Change security group/port filtering to respect known routers: - tenant routers attached to subnets and passing v6 - physical routers on provider networks provided on the network (as some sort of admin configurable list for that network). (Security issue: One VM sharing a neutron network can divert outgoing traffic from other VMs.) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1262759/+subscriptions From houckrj at gmail.com Tue Feb 11 11:31:11 2014 From: houckrj at gmail.com (Robert Houck) Date: Tue, 11 Feb 2014 05:31:11 -0600 Subject: [Openstack-security] Design Documentation for Secure Cloud Class Message-ID: Good day, Apologize for the direct email. I was not sure how many people would be pinged for the mailing list. If the contents would be better handled by another group and/or individuals, please let me know and I will go that route. I am a student at the University of Texas at San Antonio and am currently in a class dealing with cloud security. The project I have chosen to partake is a review of the architecture, policies, and procedures of open source cloud stacks like your project. I will be modeling the the architecture, policies, procedures, and their interactions with each other and attempting to find possible changes that would improve their security. My focus is from the virtual machines perspective and how much information it may be able to gather about the rest of the cloud operations. If you are aware of any research on this, please point me in the right direction. My current searches have not returned any results, but my knowledge in the area is limited and my search terms may be vague for the problem set. Other than the provided documentation provided on the project website, are their other documents (architecture, design, UML) that might assist me in my research? Thank you for your time, Robert Houck Student, UTSA SwRI Student Analyst (210) 587-9592 houckrj at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1260679 at bugs.launchpad.net Thu Feb 13 00:38:15 2014 From: 1260679 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 13 Feb 2014 00:38:15 -0000 Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set insecure file permissions References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com> Message-ID: <20140213003815.2327.48141.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/73112 ** Changed in: cinder Assignee: (unassigned) => Bill Owen (billowen) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1260679 Title: Multiple drivers set insecure file permissions Status in Cinder: In Progress Status in OpenStack Security Notes: New Bug description: GPFS from various places calls "chmod 666" as root: ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', path, run_as_root=True) ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', vol_path, run_as_root=True) the Huawei driver sets 777 permissions as root on some files: ./cinder/volume/drivers/huawei/ssh_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) ./cinder/volume/drivers/huawei/rest_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) the Scality driver sets 666 permissions on all volumes: cinder/volume/drivers/scality.py:     def _create_file(self, path, size):         with open(path, "ab") as f:             f.truncate(size)         os.chmod(path, 0o666) Similarly, the NFS and NEXENTA driver have an implementation of def _set_rw_permissions_for_all() that is being called on all newly created volumes. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1260679/+subscriptions From 1279849 at bugs.launchpad.net Thu Feb 13 18:12:52 2014 From: 1279849 at bugs.launchpad.net (Dolph Mathews) Date: Thu, 13 Feb 2014 18:12:52 -0000 Subject: [Openstack-security] [Bug 1279849] Re: keystone password creation and verification mismatch References: <20140213153829.1383.20321.malonedeb@chaenomeles.canonical.com> Message-ID: <20140213181252.5464.26653.malone@soybean.canonical.com> Well, it does present a vulnerability in that keystone is "tricked" into storing passwords in plaintext, however users have to take special action to expose themselves (odds are, I'm guessing, knowingly). ** Changed in: keystone Importance: Undecided => High ** Changed in: keystone Milestone: None => icehouse-3 ** Changed in: keystone Status: New => Triaged -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1279849 Title: keystone password creation and verification mismatch Status in OpenStack Identity (Keystone): Triaged Bug description: In keystone stable/Havana release, password for a user can be set during user creation process. Now if a user initially do a sha512 hash of his password and sent it to the keystone server over the wire, then hash_password method of keystone/common/utils.py def hash_password(password): ~ | """Hash a password. Hard.""" ~ | password_utf8 = trunc_password(password).encode('utf-8') ~ | if passlib.hash.sha512_crypt.identify(password_utf8): ~ | return password_utf8 ~ | h = passlib.hash.sha512_crypt.encrypt(password_utf8, ~ | rounds=CONF.crypt_strength) ~ | return h will not do any hashing, or it directly store the password in DB. However, during authentication, the user needs to provide the clear text password for authentication because during authentication it always does sha512 over the password field (it does not check the password is already hashed) def check_password(password, hashed): ""Check that a plaintext password matches hashed. hashpw returns the salt value concatenated with the actual hash value. It extracts the actual salt if this value is then passed as the salt. """ if password is None or hashed is None: return False password_utf8 = trunc_password(password).encode('utf-8') return passlib.hash.sha512_crypt.verify(password_utf8, hashed) Now in this case, 1) user chooses a password which is similar to a sha512 output, now keystone thinks it is already hashed, so it will store it as it is. User provides the sha512 during authentication but he cannot login this time cause now the password is hashed before matching. There should be consistency for both password creation and verification process. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1279849/+subscriptions From facundo.n.maldonado at intel.com Mon Feb 17 13:09:38 2014 From: facundo.n.maldonado at intel.com (Facundo Maldonado) Date: Mon, 17 Feb 2014 13:09:38 -0000 Subject: [Openstack-security] [Bug 1252519] Re: Live migration failed because of file permission changed References: <20131119003108.27374.76789.malonedeb@gac.canonical.com> Message-ID: <20140217130941.2122.72442.launchpad@soybean.canonical.com> ** Changed in: nova Assignee: (unassigned) => Facundo Maldonado (facundo-n-maldonado) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1252519 Title: Live migration failed because of file permission changed Status in OpenStack Compute (Nova): Triaged Bug description: Openstack : Havana OS : CentOS 6.4 Shared storage with GlusterFS : /var/lib/nova/instances mounted on glusterfs shared Instance start up fine on node01. When live migration happen, it moved to node02 but failed with the following error 2013-11-18 16:27:37.813 9837 ERROR nova.openstack.common.periodic_task [-] Error during ComputeManager.update_available_resource: Unexpected error while running command. Command: env LC_ALL=C LANG=C qemu-img info /var/lib/nova/instances/aa1deb40-ae1d-45e4-a37e-7b0607df372f/disk Exit code: 1 Stdout: '' Stderr: "qemu-img: Could not open '/var/lib/nova/instances/aa1deb40-ae1d-45e4-a37e-7b0607df372f/disk'\n" 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task Traceback (most recent call last): 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task File "/usr/lib/python2.6/site-packages/nova/openstack/common/periodic_task.py", line 180, in run_periodic_tasks 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task task(self, context) The problem is with the file ownership of "console.log" and "disk". Those file should be owned by user "qemu" and group "qemu" but after the migration, both files are owned by root drwxr-xr-x 2 nova nova 53 Nov 18 13:40 . drwxr-xr-x 6 nova nova 110 Nov 18 13:43 .. -rw-rw---- 1 root root 1546 Nov 18 13:43 console.log -rw-r--r-- 1 root root 12058624 Nov 18 13:42 disk -rw-r--r-- 1 nova nova 1569 Nov 18 13:42 libvirt.xml To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1252519/+subscriptions From gerrit2 at review.openstack.org Mon Feb 17 19:15:34 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 17 Feb 2014 19:15:34 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit fc4a41a30738ab0015a118565d55738b332e2173 Author: Dan Genin Date: Thu Jan 2 09:45:11 2014 -0500 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From gerrit2 at review.openstack.org Mon Feb 17 19:32:03 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 17 Feb 2014 19:32:03 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/70228 Log: commit 65a22f708d14ea021b470915ddd7308f7e76e24d Author: Kaitlin Farr Date: Mon Feb 3 12:16:51 2014 -0500 Adds ephemeral storage encryption for Raw back-end images This patch adds ephemeral storage encryption for Raw back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue is not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Change-Id: I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Implements: blueprint encrypt-ephemeral-storage DocImpact SecurityImpact From fungi at yuggoth.org Mon Feb 17 19:56:55 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 17 Feb 2014 19:56:55 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20140217195655.2119.49295.malone@gac.canonical.com> Switched to public following discussion with Mark. ** Information type changed from Private Security to Public ** Tags added: security ** Changed in: ossa Status: Incomplete => Invalid -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): New Status in OpenStack Security Advisories: Invalid Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From gerrit2 at review.openstack.org Mon Feb 17 20:59:12 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 17 Feb 2014 20:59:12 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit 197d707a247d9661b91d0c5e4d87636882b5e19a Author: Dan Genin Date: Thu Jan 2 09:45:11 2014 -0500 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From gerrit2 at review.openstack.org Mon Feb 17 21:14:35 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 17 Feb 2014 21:14:35 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/70228 Log: commit 851fc25fc2a4148d36a870aee2533fa291084bd2 Author: Kaitlin Farr Date: Mon Feb 3 12:16:51 2014 -0500 Adds ephemeral storage encryption for Raw back-end images This patch adds ephemeral storage encryption for Raw back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue is not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Change-Id: I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Implements: blueprint encrypt-ephemeral-storage DocImpact SecurityImpact From gerrit2 at review.openstack.org Mon Feb 17 21:51:41 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 17 Feb 2014 21:51:41 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/70228 Log: commit f8fe1779f7c0b4f469e68d54304fb3f0e74c97fe Author: Kaitlin Farr Date: Mon Feb 3 12:16:51 2014 -0500 Adds ephemeral storage encryption for Raw back-end images This patch adds ephemeral storage encryption for Raw back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue is not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Change-Id: I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Implements: blueprint encrypt-ephemeral-storage DocImpact SecurityImpact From gerrit2 at review.openstack.org Mon Feb 17 22:38:31 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 17 Feb 2014 22:38:31 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/70228 Log: commit cc162c5602208251f1fc19c539014d50c0bc526c Author: Kaitlin Farr Date: Mon Feb 3 12:16:51 2014 -0500 Adds ephemeral storage encryption for Raw back-end images This patch adds ephemeral storage encryption for Raw back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue is not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Change-Id: I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Implements: blueprint encrypt-ephemeral-storage DocImpact SecurityImpact From gerrit2 at review.openstack.org Tue Feb 18 15:16:02 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 18 Feb 2014 15:16:02 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/70228 Log: commit fbb20325f7ce6ebd66dd1dfcb9aa15d79b0d7848 Author: Kaitlin Farr Date: Mon Feb 3 12:16:51 2014 -0500 Adds ephemeral storage encryption for Raw back-end images This patch adds ephemeral storage encryption for Raw back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue is not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Change-Id: I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71 Implements: blueprint encrypt-ephemeral-storage DocImpact SecurityImpact From dstanek at dstanek.com Tue Feb 18 18:05:20 2014 From: dstanek at dstanek.com (David Stanek) Date: Tue, 18 Feb 2014 18:05:20 -0000 Subject: [Openstack-security] [Bug 1279849] Re: keystone password creation and verification mismatch References: <20140213153829.1383.20321.malonedeb@chaenomeles.canonical.com> Message-ID: <20140218180522.2216.6815.launchpad@wampee.canonical.com> ** Changed in: keystone Assignee: (unassigned) => David Stanek (dstanek) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1279849 Title: keystone password creation and verification mismatch Status in OpenStack Identity (Keystone): Triaged Bug description: In keystone stable/Havana release, password for a user can be set during user creation process. Now if a user initially do a sha512 hash of his password and sent it to the keystone server over the wire, then hash_password method of keystone/common/utils.py def hash_password(password): ~ | """Hash a password. Hard.""" ~ | password_utf8 = trunc_password(password).encode('utf-8') ~ | if passlib.hash.sha512_crypt.identify(password_utf8): ~ | return password_utf8 ~ | h = passlib.hash.sha512_crypt.encrypt(password_utf8, ~ | rounds=CONF.crypt_strength) ~ | return h will not do any hashing, or it directly store the password in DB. However, during authentication, the user needs to provide the clear text password for authentication because during authentication it always does sha512 over the password field (it does not check the password is already hashed) def check_password(password, hashed): ""Check that a plaintext password matches hashed. hashpw returns the salt value concatenated with the actual hash value. It extracts the actual salt if this value is then passed as the salt. """ if password is None or hashed is None: return False password_utf8 = trunc_password(password).encode('utf-8') return passlib.hash.sha512_crypt.verify(password_utf8, hashed) Now in this case, 1) user chooses a password which is similar to a sha512 output, now keystone thinks it is already hashed, so it will store it as it is. User provides the sha512 during authentication but he cannot login this time cause now the password is hashed before matching. There should be consistency for both password creation and verification process. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1279849/+subscriptions From 1279849 at bugs.launchpad.net Wed Feb 19 18:28:55 2014 From: 1279849 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 19 Feb 2014 18:28:55 -0000 Subject: [Openstack-security] [Bug 1279849] Re: keystone password creation and verification mismatch References: <20140213153829.1383.20321.malonedeb@chaenomeles.canonical.com> Message-ID: <20140219182855.1631.41182.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/74801 ** Changed in: keystone Status: Triaged => 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/1279849 Title: keystone password creation and verification mismatch Status in OpenStack Identity (Keystone): In Progress Bug description: In keystone stable/Havana release, password for a user can be set during user creation process. Now if a user initially do a sha512 hash of his password and sent it to the keystone server over the wire, then hash_password method of keystone/common/utils.py def hash_password(password): ~ | """Hash a password. Hard.""" ~ | password_utf8 = trunc_password(password).encode('utf-8') ~ | if passlib.hash.sha512_crypt.identify(password_utf8): ~ | return password_utf8 ~ | h = passlib.hash.sha512_crypt.encrypt(password_utf8, ~ | rounds=CONF.crypt_strength) ~ | return h will not do any hashing, or it directly store the password in DB. However, during authentication, the user needs to provide the clear text password for authentication because during authentication it always does sha512 over the password field (it does not check the password is already hashed) def check_password(password, hashed): ""Check that a plaintext password matches hashed. hashpw returns the salt value concatenated with the actual hash value. It extracts the actual salt if this value is then passed as the salt. """ if password is None or hashed is None: return False password_utf8 = trunc_password(password).encode('utf-8') return passlib.hash.sha512_crypt.verify(password_utf8, hashed) Now in this case, 1) user chooses a password which is similar to a sha512 output, now keystone thinks it is already hashed, so it will store it as it is. User provides the sha512 during authentication but he cannot login this time cause now the password is hashed before matching. There should be consistency for both password creation and verification process. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1279849/+subscriptions From dstanek at dstanek.com Wed Feb 19 22:51:42 2014 From: dstanek at dstanek.com (David Stanek) Date: Wed, 19 Feb 2014 22:51:42 -0000 Subject: [Openstack-security] [Bug 1279849] Re: keystone password creation and verification mismatch References: <20140213153829.1383.20321.malonedeb@chaenomeles.canonical.com> Message-ID: <20140219225142.1994.2964.malone@wampee.canonical.com> In my proposed fix I took the stance that we should always be treating user input as untrusted. Just hash it and move on. The code that checked if the password was already hash seemed to have been written so that a migration process could use the same API code to move users around. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1279849 Title: keystone password creation and verification mismatch Status in OpenStack Identity (Keystone): In Progress Bug description: In keystone stable/Havana release, password for a user can be set during user creation process. Now if a user initially do a sha512 hash of his password and sent it to the keystone server over the wire, then hash_password method of keystone/common/utils.py def hash_password(password): ~ | """Hash a password. Hard.""" ~ | password_utf8 = trunc_password(password).encode('utf-8') ~ | if passlib.hash.sha512_crypt.identify(password_utf8): ~ | return password_utf8 ~ | h = passlib.hash.sha512_crypt.encrypt(password_utf8, ~ | rounds=CONF.crypt_strength) ~ | return h will not do any hashing, or it directly store the password in DB. However, during authentication, the user needs to provide the clear text password for authentication because during authentication it always does sha512 over the password field (it does not check the password is already hashed) def check_password(password, hashed): ""Check that a plaintext password matches hashed. hashpw returns the salt value concatenated with the actual hash value. It extracts the actual salt if this value is then passed as the salt. """ if password is None or hashed is None: return False password_utf8 = trunc_password(password).encode('utf-8') return passlib.hash.sha512_crypt.verify(password_utf8, hashed) Now in this case, 1) user chooses a password which is similar to a sha512 output, now keystone thinks it is already hashed, so it will store it as it is. User provides the sha512 during authentication but he cannot login this time cause now the password is hashed before matching. There should be consistency for both password creation and verification process. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1279849/+subscriptions From damon.devops at gmail.com Thu Feb 20 07:19:36 2014 From: damon.devops at gmail.com (Wei Wang) Date: Thu, 20 Feb 2014 07:19:36 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140220071936.1663.89505.malone@wampee.canonical.com> Saeme to @Dolph's commit here:https://review.openstack.org/#/c/42467/2//COMMIT_MSG the need for patch should be re-considered. -- 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 facundo.n.maldonado at intel.com Thu Feb 20 14:16:25 2014 From: facundo.n.maldonado at intel.com (Facundo Maldonado) Date: Thu, 20 Feb 2014 14:16:25 -0000 Subject: [Openstack-security] [Bug 1252519] Re: Live migration failed because of file permission changed References: <20131119003108.27374.76789.malonedeb@gac.canonical.com> Message-ID: <20140220141626.1900.86233.malone@soybean.canonical.com> Cannot reproduce. Openstack: fresh devstack installation, 1 controller / 3 compute nodes Shared storage with GlusterFS: 2 nodes/ 2 bricks OS: Ubuntu server 12.04 Instances were migrated between compute nodes without problem. The files "console.log" and "disk" are owned by root after the first migration, but that do not prevent to keep migrating. Any other clue to try to reproduce this bug? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1252519 Title: Live migration failed because of file permission changed Status in OpenStack Compute (Nova): Triaged Bug description: Openstack : Havana OS : CentOS 6.4 Shared storage with GlusterFS : /var/lib/nova/instances mounted on glusterfs shared Instance start up fine on node01. When live migration happen, it moved to node02 but failed with the following error 2013-11-18 16:27:37.813 9837 ERROR nova.openstack.common.periodic_task [-] Error during ComputeManager.update_available_resource: Unexpected error while running command. Command: env LC_ALL=C LANG=C qemu-img info /var/lib/nova/instances/aa1deb40-ae1d-45e4-a37e-7b0607df372f/disk Exit code: 1 Stdout: '' Stderr: "qemu-img: Could not open '/var/lib/nova/instances/aa1deb40-ae1d-45e4-a37e-7b0607df372f/disk'\n" 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task Traceback (most recent call last): 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task File "/usr/lib/python2.6/site-packages/nova/openstack/common/periodic_task.py", line 180, in run_periodic_tasks 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task task(self, context) The problem is with the file ownership of "console.log" and "disk". Those file should be owned by user "qemu" and group "qemu" but after the migration, both files are owned by root drwxr-xr-x 2 nova nova 53 Nov 18 13:40 . drwxr-xr-x 6 nova nova 110 Nov 18 13:43 .. -rw-rw---- 1 root root 1546 Nov 18 13:43 console.log -rw-r--r-- 1 root root 12058624 Nov 18 13:42 disk -rw-r--r-- 1 nova nova 1569 Nov 18 13:42 libvirt.xml To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1252519/+subscriptions From gerrit2 at review.openstack.org Thu Feb 20 17:00:53 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 20 Feb 2014 17:00:53 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit f932192976e62a1d0aaa83aefa98443b37f593ac Author: Dan Genin Date: Thu Jan 2 09:45:11 2014 -0500 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From gerrit2 at review.openstack.org Thu Feb 20 17:11:45 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 20 Feb 2014 17:11:45 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit fc913b7a0a559e4dae295537c1c338b16348b2dc Author: Dan Genin Date: Thu Jan 2 09:45:11 2014 -0500 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From 1246158 at bugs.launchpad.net Thu Feb 20 17:50:23 2014 From: 1246158 at bugs.launchpad.net (Dolph Mathews) Date: Thu, 20 Feb 2014 17:50:23 -0000 Subject: [Openstack-security] [Bug 1246158] Re: randint method brings potential security issue References: <20131030013205.19024.89786.malonedeb@gac.canonical.com> Message-ID: <20140220175024.2122.93661.launchpad@soybean.canonical.com> *** This bug is a duplicate of bug 1236675 *** https://bugs.launchpad.net/bugs/1236675 ** This bug has been marked a duplicate of bug 1236675 Keystone getting oauth access token by brute-forcing oauth_verifier code -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1246158 Title: randint method brings potential security issue Status in OpenStack Identity (Keystone): New Status in OpenStack Compute (Nova): Invalid Status in OpenStack Security Advisories: Invalid Bug description: In the /keystone/contrib/oauth1/backends/sql.py, line 210, the source code is below token_dict['verifier'] = str(random.randint(1000, 9999)) This code is using randint method to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1246158/+subscriptions From robert.clark at hp.com Thu Feb 20 18:26:35 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Thu, 20 Feb 2014 18:26:35 +0000 Subject: [Openstack-security] FW: OpenStack Threat Analysis activity - OSSG In-Reply-To: References: <1882F75B-3933-4D82-882F-A7F596B0EB9E@ericsson.com> Message-ID: Including the whole security group as there was significant interest during the OSSG weekly meeting. From: Sriram Subramanian [mailto:sriram at sriramhere.com] Sent: 20 February 2014 16:35 To: Abu Shohel Ahmed Cc: Clark, Robert Graham; Grant Murphy; Mats Näslund; Makan Pourzandi Subject: Re: OpenStack Threat Analysis activity - OSSG Shohel, Friday 17.00 UTC works - though 18.00 UTC would work better for me. Are we meeting tomorrow? thanks, -Sriram On Wed, Feb 19, 2014 at 4:25 AM, Abu Shohel Ahmed > wrote: Hi, >From our last week’s, it becomes clear that we need set up a way of working process in place to take this activity forward. So here are some ideas (Please also share yours): 1. WoW: In the short time frame, - First, We should define the purpose and the concrete output of this work ( which i think, most of us here has some ideas, if we still have question - we can clear that up before moving forward). - Second issue is, how we can do threat analysis contribution in an effective manner. Here comes the collaboration issues within this group. For this, I have created a free node IRC channel ##openstack-threat-analysis ( unofficial channel, as you can see from name). Lets start biweekly (15 days) meetings from this week. Lets vote for what is the suitable time for meeting for all of us. I propose Friday at 17.00 UTC. However, i am happy to schedule the meeting based on most people preference. In the longer time frame, we should think about setting up a Threat analysis working group (could be under OSSG) to perform threat modelling of all OpenStack components - Define a clear out from this working group e.g., Threat documentation, Design guidance. - Engage developers and security minded people to the work. 2. Now on the technical side, First and foremost, we should agree on a threat modelling process that can be applied for all OpenStack services and internal components. We have some ideas that can be applied for this work Here is the link of our proposal : https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sh aring and here are two concrete implementation of applying the threat modelling process Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sh aring Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sh aring (These are work in progress documents, so by no means provide a complete picture) Lets discuss what do you guys think about the Modelling steps and its applicability with OpenStack (e.g., Keystone) Thanks, Shohel -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From sriram at sriramhere.com Thu Feb 20 18:47:41 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Thu, 20 Feb 2014 10:47:41 -0800 Subject: [Openstack-security] FW: OpenStack Threat Analysis activity - OSSG In-Reply-To: References: <1882F75B-3933-4D82-882F-A7F596B0EB9E@ericsson.com> Message-ID: Damn - i missed the meeting again :(. I will check the logs to catch up. Sorry On Thu, Feb 20, 2014 at 10:26 AM, Clark, Robert Graham wrote: > Including the whole security group as there was significant interest > during the OSSG weekly meeting. > > > > *From:* Sriram Subramanian [mailto:sriram at sriramhere.com] > *Sent:* 20 February 2014 16:35 > *To:* Abu Shohel Ahmed > *Cc:* Clark, Robert Graham; Grant Murphy; Mats Näslund; Makan Pourzandi > *Subject:* Re: OpenStack Threat Analysis activity - OSSG > > > > Shohel, > > > > Friday 17.00 UTC works - though 18.00 UTC would work better for me. Are we > meeting tomorrow? > > > > thanks, > > -Sriram > > > > On Wed, Feb 19, 2014 at 4:25 AM, Abu Shohel Ahmed < > ahmed.shohel at ericsson.com> wrote: > > Hi, > > From our last week's, it becomes clear that we need set up a way of > working process in place > to take this activity forward. > > So here are some ideas (Please also share yours): > > 1. WoW: > > In the short time frame, > > - First, We should define the purpose and the concrete output of > this work ( which i think, most of us here has some ideas, if we still have > question - > we can clear that up before moving forward). > > - Second issue is, how we can do threat analysis contribution in an > effective manner. Here comes the collaboration issues within > this group. For this, I have created a free node IRC channel > ##openstack-threat-analysis ( unofficial channel, as you can see from > name). > Lets start biweekly (15 days) meetings from this week. Lets vote > for what is the suitable time for meeting for all of us. > I propose Friday at 17.00 UTC. However, i am happy to schedule the > meeting based on most people preference. > > In the longer time frame, we should think about setting up a Threat > analysis working group (could be under OSSG) to perform threat modelling of > all OpenStack components > - Define a clear out from this working group e.g., Threat > documentation, Design guidance. > - Engage developers and security minded people to the work. > > > 2. Now on the technical side, > > First and foremost, we should agree on a threat modelling > process that can be applied for all OpenStack services and internal > components. We have some ideas that > can be applied for this work... Here is the link of our > proposal : > > > https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing > > and here are two concrete implementation of applying > the threat modelling process... > > Keystone over all : > https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing > Keystone Token-provider: > https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing > > (These are work in progress documents, so by no means > provide a complete picture) > > Lets discuss what do you guys think about the Modelling > steps and its applicability with OpenStack (e.g., Keystone) > > > > Thanks, > Shohel > > > > > > -- > > Thanks, > > -Sriram > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1260679 at bugs.launchpad.net Thu Feb 20 20:08:48 2014 From: 1260679 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 20 Feb 2014 20:08:48 -0000 Subject: [Openstack-security] [Bug 1260679] Fix merged to cinder (master) References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com> Message-ID: <20140220200848.1483.49694.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/73112 Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=b0ac8294dd9d8dbddfbb320c62d7264daf55be26 Submitter: Jenkins Branch: master commit b0ac8294dd9d8dbddfbb320c62d7264daf55be26 Author: Bill Owen Date: Wed Feb 12 17:37:36 2014 -0700 Update gpfs driver volume creation process Modify gpfs driver to set file permissions in a more consistent way. Modify image_utils.resize_image to allow caller to request it be run as root. SecurityImpact Change-Id: Ic01d91c0d660c74095e8d2b212279b39b9b9dc05 Partial-Bug: #1260679 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1260679 Title: Multiple drivers set insecure file permissions Status in Cinder: In Progress Status in OpenStack Security Notes: In Progress Bug description: GPFS from various places calls "chmod 666" as root: ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', path, run_as_root=True) ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', vol_path, run_as_root=True) the Huawei driver sets 777 permissions as root on some files: ./cinder/volume/drivers/huawei/ssh_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) ./cinder/volume/drivers/huawei/rest_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) the Scality driver sets 666 permissions on all volumes: cinder/volume/drivers/scality.py:     def _create_file(self, path, size):         with open(path, "ab") as f:             f.truncate(size)         os.chmod(path, 0o666) Similarly, the NFS and NEXENTA driver have an implementation of def _set_rw_permissions_for_all() that is being called on all newly created volumes. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1260679/+subscriptions From gerrit2 at review.openstack.org Thu Feb 20 21:47:39 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 20 Feb 2014 21:47:39 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit 73da6f9b152dfe7c12542bad662fe1b1fc27a9c5 Author: Dan Genin Date: Thu Jan 2 09:45:11 2014 -0500 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From ahmed.shohel at ericsson.com Fri Feb 21 11:15:08 2014 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Fri, 21 Feb 2014 13:15:08 +0200 Subject: [Openstack-security] OpenStack Threat Analysis activity - OSSG In-Reply-To: References: <1882F75B-3933-4D82-882F-A7F596B0EB9E@ericsson.com> Message-ID: <39586D6C-0734-45E2-B14B-C8F98D5ACD6F@ericsson.com> Hi guys, Sorry for not including the whole OSSG in the initial call. So, we are having an initial call for Threat modelling of OpenStack (first one is Keystone) today, 21 Feb, 17.00 UTC. Let’s have the discussion today then decide what time suits us best for later meetings. It is in Free node channel ##openstack-threat-analysis (unofficial channel). Today’s topics of discussion: 1. Threat modelling process https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing First, we t need to agree on this, so we have conformity around the whole work. Please feel free to provide your feedback. 2. Some concrete example use of the modelling process Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing (Now this documents are work in progress work, things are not always in order and complete) See you in the meeting, Shohel On 20 Feb 2014, at 20:47, Sriram Subramanian wrote: > Damn - i missed the meeting again :(. I will check the logs to catch up. Sorry > > > On Thu, Feb 20, 2014 at 10:26 AM, Clark, Robert Graham wrote: > Including the whole security group as there was significant interest during the OSSG weekly meeting. > > > > From: Sriram Subramanian [mailto:sriram at sriramhere.com] > Sent: 20 February 2014 16:35 > To: Abu Shohel Ahmed > Cc: Clark, Robert Graham; Grant Murphy; Mats Näslund; Makan Pourzandi > Subject: Re: OpenStack Threat Analysis activity - OSSG > > > > Shohel, > > > > Friday 17.00 UTC works - though 18.00 UTC would work better for me. Are we meeting tomorrow? > > > > thanks, > > -Sriram > > > > On Wed, Feb 19, 2014 at 4:25 AM, Abu Shohel Ahmed wrote: > > Hi, > > From our last week’s, it becomes clear that we need set up a way of working process in place > to take this activity forward. > > So here are some ideas (Please also share yours): > > 1. WoW: > > In the short time frame, > > - First, We should define the purpose and the concrete output of this work ( which i think, most of us here has some ideas, if we still have question - > we can clear that up before moving forward). > > - Second issue is, how we can do threat analysis contribution in an effective manner. Here comes the collaboration issues within > this group. For this, I have created a free node IRC channel ##openstack-threat-analysis ( unofficial channel, as you can see from name). > Lets start biweekly (15 days) meetings from this week. Lets vote for what is the suitable time for meeting for all of us. > I propose Friday at 17.00 UTC. However, i am happy to schedule the meeting based on most people preference. > > In the longer time frame, we should think about setting up a Threat analysis working group (could be under OSSG) to perform threat modelling of all OpenStack components > - Define a clear out from this working group e.g., Threat documentation, Design guidance. > - Engage developers and security minded people to the work. > > > 2. Now on the technical side, > > First and foremost, we should agree on a threat modelling process that can be applied for all OpenStack services and internal components. We have some ideas that > can be applied for this work… Here is the link of our proposal : > > https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing > > and here are two concrete implementation of applying the threat modelling process… > > Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing > Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing > > (These are work in progress documents, so by no means provide a complete picture) > > Lets discuss what do you guys think about the Modelling steps and its applicability with OpenStack (e.g., Keystone) > > > > Thanks, > Shohel > > > > > > > > -- > > Thanks, > > -Sriram > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > > -- > Thanks, > -Sriram > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4163 bytes Desc: not available URL: From thierry.carrez+lp at gmail.com Fri Feb 21 16:01:05 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 21 Feb 2014 16:01:05 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20140221160105.31867.60922.malone@gac.canonical.com> Change was replaced by https://review.openstack.org/#/c/74193/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): In Progress Status in neutron havana series: New Status in OpenStack Security Advisories: Confirmed Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1244025/+subscriptions From gerrit2 at review.openstack.org Sat Feb 22 20:11:41 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 22 Feb 2014 20:11:41 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I4537bae181fb61a610612e6579d516b3cb7123c5 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/75647 Log: commit 6bfececb911aabb5bfe7073ef34238e2452886ab Author: Daniel Gollub Date: Sat Feb 22 20:41:44 2014 +0100 Replace HTTPSConnection in solidfire driver Replace HTTPSConnection in solidfire driver with Requests. This introduces additional configuration options to specific a custom CA file, in case the used certificate is not covered by the system CAs. As well as an option to disable SSL verification of HTTPS connections. SSL Verification is from now on enabled by default. This changes the default behaviour and is the primary intention of this change: verify SSL certificates. This might break existing configuration/setups where the SSL certificate used by the SAN would not pass the verification. SecurityImpact DocImpact Partial-Bug: #1188189 Change-Id: I4537bae181fb61a610612e6579d516b3cb7123c5 From gerrit2 at review.openstack.org Sat Feb 22 20:13:02 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 22 Feb 2014 20:13:02 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I4537bae181fb61a610612e6579d516b3cb7123c5 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/75647 Log: commit 29d95ec885d905215a87b889b119ae82719e95cf Author: Daniel Gollub Date: Sat Feb 22 20:41:44 2014 +0100 Replace HTTPSConnection in solidfire driver Replace HTTPSConnection in solidfire driver with Requests. This introduces additional configuration options to specific a custom CA file, in case the used certificate is not covered by the system CAs. As well as an option to disable SSL verification of HTTPS connections. SSL Verification is from now on enabled by default. This changes the default behaviour and is the primary intention of this change: verify SSL certificates. This might break existing configuration/setups where the SSL certificate used by the SAN would not pass the verification. SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: I4537bae181fb61a610612e6579d516b3cb7123c5 From 1188189 at bugs.launchpad.net Sun Feb 23 08:49:42 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Sun, 23 Feb 2014 08:49:42 -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: <20140223084944.14413.8531.launchpad@chaenomeles.canonical.com> ** Changed in: cinder Status: Confirmed => In Progress ** Changed in: cinder Assignee: (unassigned) => Daniel Gollub (d-gollub) -- 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: In Progress 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: Fix Released Status in Python client library for Keystone: Fix Released 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 gerrit2 at review.openstack.org Mon Feb 24 01:22:14 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 24 Feb 2014 01:22:14 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/59603 Log: commit 00b9cae980c0466f970c16984efdf711e698ec09 Author: Jamie Lennox Date: Tue Dec 3 12:33:28 2013 +1000 Add cryptographic key storage Adds a layer called Storage on top of the DB. The DB is a simple store retrieve interface and things going through Storage are correctly encrypted and stored to the database. Add some routes to allow setting a key through the storage interface. SecurityImpact Implements: bp key-distribution-server Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de From thierry.carrez+lp at gmail.com Mon Feb 24 13:09:20 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 24 Feb 2014 13:09:20 -0000 Subject: [Openstack-security] [Bug 1081795] Re: oslo.rootwrap IpFilter fails to prevent ip netns exec References: <20121121214352.19413.92008.malonedeb@wampee.canonical.com> Message-ID: <20140224130920.922.10436.malone@gac.canonical.com> @Dirk: let me know if you started work on this, otherwise I could pick it up. Would like to solve it before Icehouse featurefreeze. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1081795 Title: oslo.rootwrap IpFilter fails to prevent ip netns exec Status in Oslo - a Library of Common OpenStack Code: Triaged Bug description: This is an oslo.rootwrap bug. IpFilter is designed to allow any ip command, unless the second parameter is "netns" (in which case you only allow ip netns {list,add,delete}. The trick is it's trivial to work around this (just run 'ip -s netns exec'). Once that's fixed, Nova should update from using a CommandFilter to using the IpFilter for calling 'ip'. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1081795/+subscriptions From gerrit2 at review.openstack.org Mon Feb 24 17:07:35 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 24 Feb 2014 17:07:35 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I20ddab5c3359071daf7505268c72331e4c786987 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/75927 Log: commit 8e1bcb38e1a49d929134c72abeee2eb3aabc8950 Author: Thomas Leaman Date: Mon Feb 24 17:03:33 2014 +0000 Bump python-swiftclient version https://review.openstack.org/#/c/69187/ introduced SSL certificate checking in python-swiftclient (released as v2.0). This patch ensures that the version of swiftclient used will verify SSL certificates correctly. This patch also documents the `swift_store_auth_insecure` configuration option for bypassing the cert verification DocImpact SecurityImpact Change-Id: I20ddab5c3359071daf7505268c72331e4c786987 From gerrit2 at review.openstack.org Mon Feb 24 17:12:18 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 24 Feb 2014 17:12:18 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I20ddab5c3359071daf7505268c72331e4c786987 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/75927 Log: commit 82dded8a7ebaf40420511a8fb34695dbd87bc92b Author: Thomas Leaman Date: Mon Feb 24 17:03:33 2014 +0000 Bump python-swiftclient version https://review.openstack.org/#/c/69187/ introduced SSL certificate checking in python-swiftclient (released as v2.0). This patch ensures that the version of swiftclient used will verify SSL certificates correctly. This patch also documents the `swift_store_auth_insecure` configuration option for bypassing the cert verification DocImpact SecurityImpact Change-Id: I20ddab5c3359071daf7505268c72331e4c786987 From 1279849 at bugs.launchpad.net Tue Feb 25 05:38:37 2014 From: 1279849 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 25 Feb 2014 05:38:37 -0000 Subject: [Openstack-security] [Bug 1279849] Re: keystone password creation and verification mismatch References: <20140213153829.1383.20321.malonedeb@chaenomeles.canonical.com> Message-ID: <20140225053838.14745.45054.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/74801 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=e492bbc68ef41b276a0a18c6dbeda242d46b66f4 Submitter: Jenkins Branch: master commit e492bbc68ef41b276a0a18c6dbeda242d46b66f4 Author: David Stanek Date: Wed Feb 19 18:26:58 2014 +0000 Always hash passwords on their way into the DB Way back in ed793ad5 a feature was added to detect if a password was already hashed. If it looked like it was already hashed the password was put into the database as is. It appears that this was added to support a migration that was using the identity API to store users instead of direct database inserts. Change-Id: I37b575e4db2fa7090c5171b8bc32cf2c57ad6e03 Fixes-bug: #1279849 ** Changed in: keystone 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/1279849 Title: keystone password creation and verification mismatch Status in OpenStack Identity (Keystone): Fix Committed Bug description: In keystone stable/Havana release, password for a user can be set during user creation process. Now if a user initially do a sha512 hash of his password and sent it to the keystone server over the wire, then hash_password method of keystone/common/utils.py def hash_password(password): ~ | """Hash a password. Hard.""" ~ | password_utf8 = trunc_password(password).encode('utf-8') ~ | if passlib.hash.sha512_crypt.identify(password_utf8): ~ | return password_utf8 ~ | h = passlib.hash.sha512_crypt.encrypt(password_utf8, ~ | rounds=CONF.crypt_strength) ~ | return h will not do any hashing, or it directly store the password in DB. However, during authentication, the user needs to provide the clear text password for authentication because during authentication it always does sha512 over the password field (it does not check the password is already hashed) def check_password(password, hashed): ""Check that a plaintext password matches hashed. hashpw returns the salt value concatenated with the actual hash value. It extracts the actual salt if this value is then passed as the salt. """ if password is None or hashed is None: return False password_utf8 = trunc_password(password).encode('utf-8') return passlib.hash.sha512_crypt.verify(password_utf8, hashed) Now in this case, 1) user chooses a password which is similar to a sha512 output, now keystone thinks it is already hashed, so it will store it as it is. User provides the sha512 during authentication but he cannot login this time cause now the password is hashed before matching. There should be consistency for both password creation and verification process. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1279849/+subscriptions From gerrit2 at review.openstack.org Wed Feb 26 10:02:08 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 26 Feb 2014 10:02:08 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Ie6a6620685995add56f38dc34c9a0a733558146a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/76476 Log: commit 31a164ac93acfe82c9f07915b725e5608937a5a6 Author: Daniel Gollub Date: Wed Feb 26 06:56:13 2014 +0100 Replace httplib.HTTPSConnection in ec2_token httplib.HTTPSConnection is known to not verify SSL certificates in Python 2.x. Implementaiton got adapted to make use of the requests module instead. SSL Verification is from now on enabled by default. Can be disabled via an addiitonal introduced configuration option: `keystone_ec2_insecure=True` SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: Ie6a6620685995add56f38dc34c9a0a733558146a From 1188189 at bugs.launchpad.net Wed Feb 26 10:02:04 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 26 Feb 2014 10:02:04 -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: <20140226100204.20802.74041.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/76476 ** Changed in: keystone Status: Confirmed => In Progress ** Changed in: keystone Assignee: (unassigned) => Daniel Gollub (d-gollub) -- 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: In Progress Status in OpenStack Identity (Keystone): In Progress 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: Fix Released Status in Python client library for Keystone: Fix Released 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 gerrit2 at review.openstack.org Wed Feb 26 11:33:08 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 26 Feb 2014 11:33:08 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Ie6a6620685995add56f38dc34c9a0a733558146a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/76476 Log: commit b55d0dfe9291aecf917441bed781ef4f404ba9be Author: Daniel Gollub Date: Wed Feb 26 06:56:13 2014 +0100 Replace httplib.HTTPSConnection in ec2_token httplib.HTTPSConnection is known to not verify SSL certificates in Python 2.x. Implementaiton got adapted to make use of the requests module instead. SSL Verification is from now on enabled by default. Can be disabled via an addiitonal introduced configuration option: `keystone_ec2_insecure=True` SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: Ie6a6620685995add56f38dc34c9a0a733558146a From gerrit2 at review.openstack.org Thu Feb 27 19:29:47 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 27 Feb 2014 19:29:47 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit bedb0628ebdc96881d9dcc7b4d615694930f5dcd Author: Dan Genin Date: Thu Jan 2 09:45:11 2014 -0500 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From bdpayne at acm.org Thu Feb 27 20:35:37 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Thu, 27 Feb 2014 12:35:37 -0800 Subject: [Openstack-security] Process for OSSG Lead Elections Message-ID: As discussed in the past two OSSG meetings, Rob and I will be stepping down as the co-leaders of OSSG at the summit in May. We would like to have an election process to choose the next leader as this is a community driven group. I've been working out the specific details for the election, which is largely based on the PTL / TC election process used by the broader OpenStack community. To ensure that everyone is up to speed, please review the election process: https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014 We began discussing this in the OSSG meeting today. Some initial areas of discussion were around the following points: 1) Is attending a single IRC meeting sufficient to be considered an "active member"? Perhaps we should increase this requirement to 3 or more meetings? 2) Does the current proposed timeline work? There may be other items that catch people's eyes as well. Please use this thread to discuss the process and suggest improvements. I will help mediate that discussion with the goal of arriving at something we all feel comfortable with. Cheers, -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerrit2 at review.openstack.org Thu Feb 27 21:00:02 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 27 Feb 2014 21:00:02 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Ie6a6620685995add56f38dc34c9a0a733558146a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/76476 Log: commit c7a048fca557e94dbb4b62472ed9b63304b5e04d Author: Daniel Gollub Date: Wed Feb 26 06:56:13 2014 +0100 Replace httplib.HTTPSConnection in ec2_token httplib.HTTPSConnection is known to not verify SSL certificates in Python 2.x. Implementation got adapted to make use of the requests module instead. SSL Verification is from now on enabled by default. Can be disabled via an additional introduced configuration option: `keystone_ec2_insecure=True` SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: Ie6a6620685995add56f38dc34c9a0a733558146a From gerrit2 at review.openstack.org Thu Feb 27 21:58:24 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 27 Feb 2014 21:58:24 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Ie6a6620685995add56f38dc34c9a0a733558146a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/76476 Log: commit ef3e98ef161eb43b1e3bdab2e402404b747047df Author: Daniel Gollub Date: Wed Feb 26 06:56:13 2014 +0100 Replace httplib.HTTPSConnection in ec2_token httplib.HTTPSConnection is known to not verify SSL certificates in Python 2.x. Implementation got adapted to make use of the requests module instead. SSL Verification is from now on enabled by default. Can be disabled via an additional introduced configuration option: `keystone_ec2_insecure=True` SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: Ie6a6620685995add56f38dc34c9a0a733558146a From gerrit2 at review.openstack.org Thu Feb 27 22:11:37 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 27 Feb 2014 22:11:37 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I10fbb706b34ca5e29d86c369d9e83d8518f24867 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/76987 Log: commit a326d24294be7cbd74c6b0941e212dbec7bbe8b0 Author: Daniel Gollub Date: Thu Feb 27 23:06:21 2014 +0100 Replace HTTPSConnection in bigswitch driver Replace HTTPSConnection in bigswitch driver with Requests. SSL Verification is from now on enabled by default. This changes the default behaviour and is the primary intention of this change: verify SSL certificates. This might break existing configuration/setups where the SSL certificate used by the bigswitch driver would not pass the verification. SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: I10fbb706b34ca5e29d86c369d9e83d8518f24867 From 1188189 at bugs.launchpad.net Thu Feb 27 22:11:33 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 27 Feb 2014 22:11: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: <20140227221133.26907.14602.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/76987 ** Changed in: neutron Status: Confirmed => In Progress ** Changed in: neutron Assignee: (unassigned) => Daniel Gollub (d-gollub) -- 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: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released 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 gerrit2 at review.openstack.org Fri Feb 28 00:43:17 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 28 Feb 2014 00:43:17 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I10fbb706b34ca5e29d86c369d9e83d8518f24867 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/76987 Log: commit 5f6a7e34acda9144e6fefaf8da1df00b916424d5 Author: Daniel Gollub Date: Thu Feb 27 23:06:21 2014 +0100 Replace HTTPSConnection in bigswitch driver Replace HTTPSConnection in bigswitch driver with Requests. SSL Verification is from now on enabled by default. This changes the default behaviour and is the primary intention of this change: verify SSL certificates. This might break existing configuration/setups where the SSL certificate used by the bigswitch driver would not pass the verification. SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: I10fbb706b34ca5e29d86c369d9e83d8518f24867 From robert.clark at hp.com Fri Feb 28 12:15:13 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Fri, 28 Feb 2014 12:15:13 +0000 Subject: [Openstack-security] OSSNs are stacking up Message-ID: https://bugs.launchpad.net/ossn Any volunteers to help out writing these up? -Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From SHULMANA at il.ibm.com Fri Feb 28 14:03:22 2014 From: SHULMANA at il.ibm.com (Alexandra Shulman-Peleg) Date: Fri, 28 Feb 2014 16:03:22 +0200 Subject: [Openstack-security] AUTO: Alexandra Shulman-Peleg is out of the office. (returning 04/03/2014) Message-ID: I am out of the office until 04/03/2014. I am out of office. If required, please contact my manager Dalit Naor (dalit at il.ibm.com). Note: This is an automated response to your message "Openstack-security Digest, Vol 12, Issue 27" sent on 28/02/2014 14:00:02. This is the only notification you will receive while this person is away. From binhou at cn.ibm.com Tue Feb 18 01:49:07 2014 From: binhou at cn.ibm.com (Bin Hou) Date: Tue, 18 Feb 2014 01:49:07 -0000 Subject: [Openstack-security] [Bug 1246158] Re: randint method brings potential security issue References: <20131030013205.19024.89786.malonedeb@gac.canonical.com> Message-ID: <20140218014907.2249.64306.malone@soybean.canonical.com> Could you help to find someone in keystone group to take a look at this bug? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1246158 Title: randint method brings potential security issue Status in OpenStack Compute (Nova): Invalid Status in OpenStack Security Advisories: Invalid Bug description: In the /keystone/contrib/oauth1/backends/sql.py, line 210, the source code is below token_dict['verifier'] = str(random.randint(1000, 9999)) This code is using randint method to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1246158/+subscriptions From binhou at cn.ibm.com Tue Feb 18 01:52:43 2014 From: binhou at cn.ibm.com (Bin Hou) Date: Tue, 18 Feb 2014 01:52:43 -0000 Subject: [Openstack-security] [Bug 1246159] Re: seed method brings potential security issue References: <20131030013717.19024.324.malonedeb@gac.canonical.com> Message-ID: <20140218015243.2001.45542.malone@gac.canonical.com> Could you help to find someone in cinder group to take a look at this bug? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1246159 Title: seed method brings potential security issue Status in OpenStack Compute (Nova): Invalid Status in OpenStack Security Advisories: Invalid Bug description: In the /cinder/transfer/apil.py, line 86, the source code is below random.seed(datetime.datetime.now().microsecond) This code is using seed method to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1246159/+subscriptions From bknudson at us.ibm.com Thu Feb 20 16:27:26 2014 From: bknudson at us.ibm.com (Brant Knudson) Date: Thu, 20 Feb 2014 16:27:26 -0000 Subject: [Openstack-security] [Bug 1246158] Re: randint method brings potential security issue References: <20131030013205.19024.89786.malonedeb@gac.canonical.com> Message-ID: <20140220162726.2068.26759.launchpad@wampee.canonical.com> ** Also affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1246158 Title: randint method brings potential security issue Status in OpenStack Identity (Keystone): New Status in OpenStack Compute (Nova): Invalid Status in OpenStack Security Advisories: Invalid Bug description: In the /keystone/contrib/oauth1/backends/sql.py, line 210, the source code is below token_dict['verifier'] = str(random.randint(1000, 9999)) This code is using randint method to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1246158/+subscriptions From 1274034 at bugs.launchpad.net Fri Feb 21 20:50:35 2014 From: 1274034 at bugs.launchpad.net (Mark McClain) Date: Fri, 21 Feb 2014 20:50:35 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20140221205038.14372.34260.launchpad@chaenomeles.canonical.com> ** Changed in: neutron Status: New => Triaged ** Tags added: l3-ipam-dhcp -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): Triaged Status in OpenStack Security Advisories: Invalid Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From d.gollub at telekom.de Sat Feb 22 11:23:51 2014 From: d.gollub at telekom.de (Daniel Gollub) Date: Sat, 22 Feb 2014 11:23:51 -0000 Subject: [Openstack-security] [Bug 1250101] Re: Cinder's rootwrap filters allow to run find as root, which allows arbitrary commands References: <20131111144450.24249.16674.malonedeb@gac.canonical.com> Message-ID: <20140222112354.31133.31699.launchpad@soybean.canonical.com> ** Changed in: cinder Assignee: (unassigned) => Daniel Gollub (d-gollub) ** Changed in: cinder Status: New => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1250101 Title: Cinder's rootwrap filters allow to run find as root, which allows arbitrary commands Status in Cinder: In Progress Status in Oslo - a Library of Common OpenStack Code: Invalid Status in OpenStack Security Advisories: Invalid Bug description: The patch https://github.com/openstack/cinder/commit/688c515b9d662486395d36c303ca599376a1dc0d added the find command to etc/cinder/rootwrap.d/volume.filters. This introduces a security hole as the find command is able to call exec, and so the cinder user can run any command as root. For example: vagrant at controller:~$ sudo -u cinder bash cinder at controller:~$ id uid=109(cinder) gid=115(cinder) groups=115(cinder) cinder at controller:~$ sudo /usr/bin/cinder-rootwrap /etc/cinder/rootwrap.conf find /etc/hosts -exec bash \; root at controller:~# id uid=0(root) gid=0(root) groups=0(root) I guess the way to fix this is to add a FindFilter to Oslo that rejects calls to find with the -exec or -execdir argument. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1250101/+subscriptions From 1250101 at bugs.launchpad.net Sat Feb 22 11:27:56 2014 From: 1250101 at bugs.launchpad.net (OpenStack Infra) Date: Sat, 22 Feb 2014 11:27:56 -0000 Subject: [Openstack-security] [Bug 1250101] Re: Cinder's rootwrap filters allow to run find as root, which allows arbitrary commands References: <20131111144450.24249.16674.malonedeb@gac.canonical.com> Message-ID: <20140222112756.14481.72158.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/75629 ** 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/1250101 Title: Cinder's rootwrap filters allow to run find as root, which allows arbitrary commands Status in Cinder: In Progress Status in Oslo - a Library of Common OpenStack Code: Invalid Status in OpenStack Security Advisories: Invalid Bug description: The patch https://github.com/openstack/cinder/commit/688c515b9d662486395d36c303ca599376a1dc0d added the find command to etc/cinder/rootwrap.d/volume.filters. This introduces a security hole as the find command is able to call exec, and so the cinder user can run any command as root. For example: vagrant at controller:~$ sudo -u cinder bash cinder at controller:~$ id uid=109(cinder) gid=115(cinder) groups=115(cinder) cinder at controller:~$ sudo /usr/bin/cinder-rootwrap /etc/cinder/rootwrap.conf find /etc/hosts -exec bash \; root at controller:~# id uid=0(root) gid=0(root) groups=0(root) I guess the way to fix this is to add a FindFilter to Oslo that rejects calls to find with the -exec or -execdir argument. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1250101/+subscriptions From d.gollub at telekom.de Sun Feb 23 00:02:19 2014 From: d.gollub at telekom.de (Daniel Gollub) Date: Sun, 23 Feb 2014 00:02:19 -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: <20140223000219.23879.58658.malone@wampee.canonical.com> cinder: Replace HTTPSConnection in solidfire driver https://review.openstack.org/#/c/75647/ -- 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: Fix Released Status in Python client library for Keystone: Fix Released 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 d.gollub at telekom.de Sun Feb 23 08:49:49 2014 From: d.gollub at telekom.de (Daniel Gollub) Date: Sun, 23 Feb 2014 08:49:49 -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: <20140223084949.31650.47261.malone@gac.canonical.com> cinder: Replace httplib.HTTPSConnection in unittests https://review.openstack.org/#/c/75667/ -- 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: In Progress 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: Fix Released Status in Python client library for Keystone: Fix Released 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 skywalker.nick at gmail.com Sun Feb 23 12:50:27 2014 From: skywalker.nick at gmail.com (Li Ma) Date: Sun, 23 Feb 2014 12:50:27 -0000 Subject: [Openstack-security] [Bug 1187107] Re: quantum-ns-metadata-proxy runs as root References: <20130603194234.27198.32504.malonedeb@gac.canonical.com> Message-ID: <20140223125029.31867.18017.launchpad@gac.canonical.com> ** Changed in: neutron Assignee: (unassigned) => Li Ma (nick-ma-z) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1187107 Title: quantum-ns-metadata-proxy runs as root Status in OpenStack Neutron (virtual network service): Triaged Bug description: # ps -ef | grep quantum-ns-metadata-proxy root 10239 1 0 19:01 ? 00:00:00 python /usr/bin/quantum-ns-metadata-proxy --pid_file=/var/lib/quantum/external/pids/7a44de32-3ac0-4f3e-92cc-1a37d8211db8.pid --router_id=7a44de32-3ac0-4f3e-92cc-1a37d8211db8 --state_path=/var/lib/quantum --debug --log-file=quantum-ns-metadata-proxy7a44de32-3ac0-4f3e-92cc-1a37d8211db8.log --log-dir=/var/log/quantum Root is needed to open the namespace, but the quantum-ns-metadata-proxy does not need root - it listens on 9697 by default not 80. I tried changing /etc/quantum/rootwrap.d/l3.filters for it to run as quantum instead: metadata_proxy: CommandFilter, /usr/bin/quantum-ns-metadata-proxy, quantum but it still runs as root. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1187107/+subscriptions From skywalker.nick at gmail.com Sun Feb 23 13:20:18 2014 From: skywalker.nick at gmail.com (Li Ma) Date: Sun, 23 Feb 2014 13:20:18 -0000 Subject: [Openstack-security] [Bug 1187107] Re: quantum-ns-metadata-proxy runs as root References: <20130603194234.27198.32504.malonedeb@gac.canonical.com> Message-ID: <20140223132018.14372.82867.malone@chaenomeles.canonical.com> It seems that the command is classified as ip-netns filter which will run under root permission. That's why the metadata-proxy command filter doesn't take effect. Actually it's not a 'wrong' behavior. neutron-rootwrap: (root > root) Executing ['/sbin/ip', 'netns', 'exec', 'qrouter-445757d8-ade8-4c2f-9b44-029942e9fd26', 'neutron-ns-metadata- proxy', '--pid_file=/var/lib/neutron/external/pids/445757d8-ade8-4c2f- 9b44-029942e9fd26.pid', '-- metadata_proxy_socket=/var/lib/neutron/metadata_proxy', '-- router_id=445757d8-ade8-4c2f-9b44-029942e9fd26', '-- state_path=/var/lib/neutron', '--metadata_port=9697', '--log-file =neutron-ns-metadata-proxy-445757d8-ade8-4c2f-9b44-029942e9fd26.log', '--log-dir=/var/log/neutron'] (filter match = ip_exec) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1187107 Title: quantum-ns-metadata-proxy runs as root Status in OpenStack Neutron (virtual network service): Triaged Bug description: # ps -ef | grep quantum-ns-metadata-proxy root 10239 1 0 19:01 ? 00:00:00 python /usr/bin/quantum-ns-metadata-proxy --pid_file=/var/lib/quantum/external/pids/7a44de32-3ac0-4f3e-92cc-1a37d8211db8.pid --router_id=7a44de32-3ac0-4f3e-92cc-1a37d8211db8 --state_path=/var/lib/quantum --debug --log-file=quantum-ns-metadata-proxy7a44de32-3ac0-4f3e-92cc-1a37d8211db8.log --log-dir=/var/log/quantum Root is needed to open the namespace, but the quantum-ns-metadata-proxy does not need root - it listens on 9697 by default not 80. I tried changing /etc/quantum/rootwrap.d/l3.filters for it to run as quantum instead: metadata_proxy: CommandFilter, /usr/bin/quantum-ns-metadata-proxy, quantum but it still runs as root. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1187107/+subscriptions From matt at mattfischer.com Mon Feb 24 21:53:31 2014 From: matt at mattfischer.com (Matt Fischer) Date: Mon, 24 Feb 2014 21:53:31 -0000 Subject: [Openstack-security] [Bug 1158328] Re: passwords in config files stored in plaintext References: <20130321141459.14228.40307.malonedeb@soybean.canonical.com> Message-ID: <20140224215331.851.7846.malone@gac.canonical.com> I see this bug is old and Wishlisted so it may never get fixed, but I'd like to add that plaintext passwords are generally a no-no when the service account auth is managed by Corporate AD or LDAP. It may complicate some deployments but it would be nice to have a solution to this. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1158328 Title: passwords in config files stored in plaintext Status in OpenStack Compute (Nova): Confirmed Bug description: The credentials for database conenctions and the keystone authtoken are stored in plaintext within the nova.conf and apipaste config files. These values should be encrypted. A scheme similar to /etc/shadow would be great. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1158328/+subscriptions From 1284574 at bugs.launchpad.net Tue Feb 25 11:17:07 2014 From: 1284574 at bugs.launchpad.net (Mike Scherbakov) Date: Tue, 25 Feb 2014 11:17:07 -0000 Subject: [Openstack-security] [Bug 1284574] Re: refactoring murano spec References: <20140225103901.32520.60643.malonedeb@gac.canonical.com> Message-ID: <20140225111707.23916.29502.malone@wampee.canonical.com> Both CentOS & Ubuntu are affected. Please change 766 and 777 to more secure rights (755?), or explain why we need 766/777. ** Changed in: fuel Milestone: 5.0 => 4.1 ** Changed in: fuel Status: New => Confirmed ** Tags added: security ** Summary changed: - refactoring murano spec + Murano has too open dirs (o+w) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1284574 Title: Murano has too open dirs (o+w) Status in Fuel: OpenStack installer that works: Confirmed Bug description: murano-dashboard.spec chmod 777 %{buildroot}/var/log/murano - please change 777 to right access %dir %attr(766, apache, apache) /var/cache/muranodashboard-cache - please change 777 to right access modify-horizon-config.sh maybe move to puppet ? To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1284574/+subscriptions From 1284574 at bugs.launchpad.net Tue Feb 25 11:21:24 2014 From: 1284574 at bugs.launchpad.net (Dmitry Ilyin) Date: Tue, 25 Feb 2014 11:21:24 -0000 Subject: [Openstack-security] [Bug 1284574] Re: Murano has too open dirs (o+w) References: <20140225103901.32520.60643.malonedeb@gac.canonical.com> Message-ID: <20140225112124.23216.60907.malone@wampee.canonical.com> It's hard to move modify config to Puppet because if my memory serves me right the config is Python code and it's not that easy to manage it woth Puppet. Well... template will do the job. These directories are being made by the packege scripts and there permissions are set there too. Modify package scripts to get correct permissions. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1284574 Title: Murano has too open dirs (o+w) Status in Fuel: OpenStack installer that works: Confirmed Bug description: murano-dashboard.spec chmod 777 %{buildroot}/var/log/murano - please change 777 to right access %dir %attr(766, apache, apache) /var/cache/muranodashboard-cache - please change 777 to right access modify-horizon-config.sh maybe move to puppet ? To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1284574/+subscriptions From rvyalov at mirantis.com Tue Feb 25 12:52:58 2014 From: rvyalov at mirantis.com (Roman Vyalov) Date: Tue, 25 Feb 2014 12:52:58 -0000 Subject: [Openstack-security] [Bug 1284574] Re: Murano has too open dirs (o+w) References: <20140225103901.32520.60643.malonedeb@gac.canonical.com> Message-ID: <20140225125258.32739.41586.malone@gac.canonical.com> move permissions and create dir to spec, and move other to puppet ? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1284574 Title: Murano has too open dirs (o+w) Status in Fuel: OpenStack installer that works: Confirmed Bug description: murano-dashboard.spec chmod 777 %{buildroot}/var/log/murano - please change 777 to right access %dir %attr(766, apache, apache) /var/cache/muranodashboard-cache - please change 777 to right access modify-horizon-config.sh maybe move to puppet ? To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1284574/+subscriptions From tnurlygayanov at mirantis.com Tue Feb 25 13:53:59 2014 From: tnurlygayanov at mirantis.com (Timur Nurlygayanov) Date: Tue, 25 Feb 2014 13:53:59 -0000 Subject: [Openstack-security] [Bug 1284574] Re: Murano has too open dirs (o+w) References: <20140225103901.32520.60643.malonedeb@gac.canonical.com> Message-ID: <20140225135359.14510.93670.malone@chaenomeles.canonical.com> I suggest to remove modify-horizon-config.sh from Puppet to DEB/RPN packages. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1284574 Title: Murano has too open dirs (o+w) Status in Fuel: OpenStack installer that works: Confirmed Bug description: murano-dashboard.spec chmod 777 %{buildroot}/var/log/murano - please change 777 to right access %dir %attr(766, apache, apache) /var/cache/muranodashboard-cache - please change 777 to right access modify-horizon-config.sh maybe move to puppet ? To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1284574/+subscriptions From rvyalov at mirantis.com Tue Feb 25 14:01:44 2014 From: rvyalov at mirantis.com (Roman Vyalov) Date: Tue, 25 Feb 2014 14:01:44 -0000 Subject: [Openstack-security] [Bug 1284574] Re: Murano has too open dirs (o+w) References: <20140225103901.32520.60643.malonedeb@gac.canonical.com> Message-ID: <20140225140144.32069.30963.launchpad@gac.canonical.com> ** Description changed: murano-dashboard.spec - chmod 777 %{buildroot}/var/log/murano - please change 777 to right access - %dir %attr(766, apache, apache) /var/cache/muranodashboard-cache - please change 777 to right access - - modify-horizon-config.sh maybe move to puppet ? + Please change directory access 777 and 766 to rights 755 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1284574 Title: Murano has too open dirs (o+w) Status in Fuel: OpenStack installer that works: Confirmed Bug description: murano-dashboard.spec Please change directory access 777 and 766 to rights 755 To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1284574/+subscriptions From iyozhikov at mirantis.com Tue Feb 25 16:59:30 2014 From: iyozhikov at mirantis.com (Igor Yozhikov) Date: Tue, 25 Feb 2014 16:59:30 -0000 Subject: [Openstack-security] [Bug 1284574] Re: Murano has too open dirs (o+w) References: <20140225103901.32520.60643.malonedeb@gac.canonical.com> Message-ID: <20140225165930.32003.53890.malone@gac.canonical.com> fixed for RPM at (https://gerrit.mirantis.com/#/c/13180/) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1284574 Title: Murano has too open dirs (o+w) Status in Fuel: OpenStack installer that works: Confirmed Bug description: murano-dashboard.spec Please change directory access 777 and 766 to rights 755 To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1284574/+subscriptions From rvyalov at mirantis.com Tue Feb 25 20:17:25 2014 From: rvyalov at mirantis.com (Roman Vyalov) Date: Tue, 25 Feb 2014 20:17:25 -0000 Subject: [Openstack-security] [Bug 1284574] Re: Murano has too open dirs (o+w) References: <20140225103901.32520.60643.malonedeb@gac.canonical.com> Message-ID: <20140225201726.31867.56818.launchpad@gac.canonical.com> ** Changed in: fuel Status: Confirmed => 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/1284574 Title: Murano has too open dirs (o+w) Status in Fuel: OpenStack installer that works: Fix Committed Bug description: murano-dashboard.spec Please change directory access 777 and 766 to rights 755 To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1284574/+subscriptions From 1284242 at bugs.launchpad.net Wed Feb 26 12:16:49 2014 From: 1284242 at bugs.launchpad.net (Robert Collins) Date: Wed, 26 Feb 2014 12:16:49 -0000 Subject: [Openstack-security] [Bug 1284242] Re: apache2 image element requires ssl-certs on ubuntu References: <20140224180543.23431.93762.malonedeb@wampee.canonical.com> Message-ID: <20140226121649.20699.92628.malone@soybean.canonical.com> Actually, I'd argue the bug is that we're trying to make snakeoil certificates. We should pass in the certificate needed to the machines that need it, as snakeoil is never the right production answer. Tests can make snakeoil certs on the jenkins slave. ** Changed in: tripleo Status: New => Triaged ** Changed in: tripleo Importance: Undecided => High ** Tags added: security ssl -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1284242 Title: apache2 image element requires ssl-certs on ubuntu Status in tripleo - openstack on openstack: Triaged Bug description: From os-collect-config log file on an image booted from devtest: 'make-ssl-cert: command not found' $ dpkg -S /usr/sbin/make-ssl-cert ssl-cert: /usr/sbin/make-ssl-cert [2014-02-24 17:47:49,629] (os-refresh-config) [INFO] Starting phase post-configure dib-run-parts Mon Feb 24 17:47:49 UTC 2014 Running /opt/stack/os-config-refresh/post-configure.d/15-apache2 + '[' -f /etc/debian_version ']' + openssl_cmd=openssl + cert_create_cmd='make-ssl-cert generate-default-snakeoil --force-overwrite' + snakeoil_pem_file=/etc/ssl/certs/ssl-cert-snakeoil.pem + '[' -f /etc/ssl/certs/ssl-cert-snakeoil.pem ']' + cert_chk_cmd='openssl x509 -noout -in /etc/ssl/certs/ssl-cert-snakeoil.pem' + exit_error=0 ++ openssl x509 -noout -in /etc/ssl/certs/ssl-cert-snakeoil.pem unable to load certificate 3073526024:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE + cmd_run= + exit_error=1 + '[' 1 -ne 0 ']' + exit_error=0 ++ make-ssl-cert generate-default-snakeoil --force-overwrite /opt/stack/os-config-refresh/post-configure.d/15-apache2: line 16: make-ssl-cert: command not found + cmd_run= + exit_error=1 + '[' 1 -eq 0 ']' + '[' 1 -ne 0 ']' + echo 'Error encountered setting up SSL (exit_error=1)' Error encountered setting up SSL (exit_error=1) + '[' -f /etc/debian_version ']' + service apache2 reload * Reloading web server apache2 ^[[80G ^[[31m*^[[39;49m ^[[33m*^[[39;49m Apache2 is not running To manage notifications about this bug go to: https://bugs.launchpad.net/tripleo/+bug/1284242/+subscriptions From 1250101 at bugs.launchpad.net Wed Feb 26 13:07:33 2014 From: 1250101 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 26 Feb 2014 13:07:33 -0000 Subject: [Openstack-security] [Bug 1250101] Related fix proposed to cinder (master) References: <20131111144450.24249.16674.malonedeb@gac.canonical.com> Message-ID: <20140226130733.14553.74392.malone@wampee.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/76529 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1250101 Title: Cinder's rootwrap filters allow to run find as root, which allows arbitrary commands Status in Cinder: In Progress Status in Oslo - a Library of Common OpenStack Code: Invalid Status in OpenStack Security Advisories: Invalid Bug description: The patch https://github.com/openstack/cinder/commit/688c515b9d662486395d36c303ca599376a1dc0d added the find command to etc/cinder/rootwrap.d/volume.filters. This introduces a security hole as the find command is able to call exec, and so the cinder user can run any command as root. For example: vagrant at controller:~$ sudo -u cinder bash cinder at controller:~$ id uid=109(cinder) gid=115(cinder) groups=115(cinder) cinder at controller:~$ sudo /usr/bin/cinder-rootwrap /etc/cinder/rootwrap.conf find /etc/hosts -exec bash \; root at controller:~# id uid=0(root) gid=0(root) groups=0(root) I guess the way to fix this is to add a FindFilter to Oslo that rejects calls to find with the -exec or -execdir argument. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1250101/+subscriptions From geekinutah at gmail.com Thu Feb 27 22:20:06 2014 From: geekinutah at gmail.com (Michael H Wilson) Date: Thu, 27 Feb 2014 22:20:06 -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: <20140227222008.14185.7632.launchpad@gac.canonical.com> ** Changed in: nova Assignee: (unassigned) => Michael H Wilson (geekinutah) -- 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): Confirmed 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 1250101 at bugs.launchpad.net Fri Feb 28 07:51:23 2014 From: 1250101 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 28 Feb 2014 07:51:23 -0000 Subject: [Openstack-security] [Bug 1250101] Re: Cinder's rootwrap filters allow to run find as root, which allows arbitrary commands References: <20131111144450.24249.16674.malonedeb@gac.canonical.com> Message-ID: <20140228075124.8309.18352.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/75629 Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=6af10e84e1a3f1e4673bc2f58142269a2bfeefcf Submitter: Jenkins Branch: master commit 6af10e84e1a3f1e4673bc2f58142269a2bfeefcf Author: Daniel Gollub Date: Wed Feb 19 07:37:20 2014 +0100 Restrict rootwrap find filter for NetAppNFS driver Additional make the name of the filter unique, so it does not override any other rule. Like the find rule of the GPFS driver. Rootwrap is making use of plain python ConfigParser which handles INI files with key=value pair like fashion. Where the key is unique. Closes-Bug: 1250101 Change-Id: Id2f193485089e12f00008b38fad2b95a09674ff2 ** 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/1250101 Title: Cinder's rootwrap filters allow to run find as root, which allows arbitrary commands Status in Cinder: Fix Committed Status in Oslo - a Library of Common OpenStack Code: Invalid Status in OpenStack Security Advisories: Invalid Bug description: The patch https://github.com/openstack/cinder/commit/688c515b9d662486395d36c303ca599376a1dc0d added the find command to etc/cinder/rootwrap.d/volume.filters. This introduces a security hole as the find command is able to call exec, and so the cinder user can run any command as root. For example: vagrant at controller:~$ sudo -u cinder bash cinder at controller:~$ id uid=109(cinder) gid=115(cinder) groups=115(cinder) cinder at controller:~$ sudo /usr/bin/cinder-rootwrap /etc/cinder/rootwrap.conf find /etc/hosts -exec bash \; root at controller:~# id uid=0(root) gid=0(root) groups=0(root) I guess the way to fix this is to add a FindFilter to Oslo that rejects calls to find with the -exec or -execdir argument. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1250101/+subscriptions