From openstack-security at lists.openstack.org Thu May 4 08:46:05 2017 From: openstack-security at lists.openstack.org (vmilpmvp) Date: Thu, 4 May 2017 16:46:05 +0800 Subject: [Openstack-security] =?utf-8?q?openstack-security=3A=E8=8B=B9?= =?utf-8?b?5p6c5YWs5Y+45ZCI5LyZ5Lq66IKh5p2D5LmL6LevICAxNjo0NjoxNA==?= Message-ID: <20170504164615162542@aq.org> 主题:合伙人制度---有效激励而不失控制权是如何实现的? 【时间地点】2017年5月14-15杭州 6月09-10上海 【参加对象】股东、董事及高管及对本课程感兴趣的人士 【授课方式】现场演练+案例教学+工具包应用+自己动手+老师指导点评=可落地执行方案 【学习费用】5980元/2天/1人(含学习费、教材、午餐、茶点等 ) 【垂询热线】021-31006787、0755-61280006,13381601000 许先生 【电子邮箱】320588808 at qq.com 【QQ/微信】320588808 【课程背景】 为什么现在的合伙人制度这么红火,因为资本的光环正在褪去,现在是人本为王的新时代! 在过去,是创始人单干制;在现在,提倡合伙人兵团作战。 在过去,利益是上下级分配制;在现在,提倡合伙人之间利益分享。 在过去,职业经理人用脚投票;在现在,提倡合伙人之间背靠背共进退。 【课程收益】 1、掌握合伙人的甄选、估值、分钱、退出机制。 2、掌握5种控制权丧失的有效处理方法。 3、学会规避合伙人风险的4种方法。 4、掌握合伙人与股权设计的区别。 5、情景式教学:剖析合伙人改革案例,借鉴经验、方法和教训。 6、咨询式培训:得到大量表单、工具包,拿回即用;解决培训效果的转化问题。 【工具包】 工具1:股权九轮融资模型 工具2:合伙人的选择模型 工具3:合伙人的估值模型 表单1:股东合伙协议书 表单2:有限合伙企业章程 表单3:员工虚拟股激励方案 表单4:股权代持协议书 【课程大纲】 第一部分 合伙人现状的分析----雇佣时代结束,合伙人时代到来 案例:海尔迎来合伙人时代 一、合伙人制度与股权设计的区别 二、合伙人适用的企业 第二部分 合伙人类型的选择—合在一起,成为一伙一、股东合伙人 案例:苹果公司合伙人股权之路 工具1:股权九轮融资模型:某公司第一大股东股份如何被稀释,及合伙人如何通过股权致富的? 表单1:股东合伙协议书 二、事业合伙人 案例:任正非如何玩转华为事业合伙人? 三、生态链合伙人 案例:美道家的生态链合伙人模式(2015年) 第三部分 合伙人平台的打造—平台为王,资源整合 案例:讲师合伙人是采取公司制还是合伙企业? 一、合伙企业 案例:马云如何通过合伙企业控制蚂蚁金服? 表单2:有限合伙企业章程 二、公司制 案例:乔致庸的银股和身股激励 表单3:员工虚拟股激励方案 第四部分 合伙人制度的设计—恋爱模式,操作灵活 一、合伙人如何选择 工具2:合伙人的选择模型 二、合伙人如何出资? 案例:现金出资--某企业的合伙人现金出资方案 思考:员工没钱出资,怎么办? 三、合伙人如何估值? 1、估值的方法---工具3(估值模型):PB/PS/PE 2、估值的调整—对赌协议 案例:冯小刚与华谊兄弟公司的对赌协议 四、合伙人如何分钱? 1、兜底分钱 2、增量分钱 五、合伙人如何退出? 1、荣誉合伙人 2、合伙金(股权)回购 3、IPO上市退出 案例:九鼎投资LP合伙人的退出 第五部分 实操作业(带笔记本电脑) 1、提供本企业的资料、背景等; 2、设计本企业的合伙人制度(包括合伙人甄选标准、分股权、分钱、退出机制等) 学员展示本企业的合伙人制度,老师点评总结 第六部分 合伙人股权的设计—婚姻模式,融资融智 一、股权架构的设计 案例:王宝强离婚前的股权架构布局 二、股权控制权的设计 案例1:投票权委托-----腾讯是京东第一大股东,为何影响不了刘强东的控制权? 案例2:一致行动协议-----腾讯是国外控股的公司吗? 案例3:AB股架构----- Google公司的AB股架构,确保创始人不出局 第七部分 实操作业 1、提供本企业的资料、背景等; 2、设计本企业的股权架构与控制权(学员现场演练,老师点评总结,带笔记本电脑) 第八部分 合伙人的风险—盛名之下,必有隐患 思考:合伙人制度是万能的吗? 一、道德的风险 案例:土豆网创始人王微离婚引发的“血案” 表单4:股权代持协议书 二、章程的风险 案例:万科公司的章程如何抵御门口“野蛮人” 三、涉税的风险 1、股权结构设计不合理的涉税风险 案例:VIE股权架构的涉税风险 2、股权激励中的涉税事项 四、知情权的风险 案例:真功夫公司股东知情权纠纷案 【讲师简介】 郑指梁 实战人力资源&财务管理专家 管理学硕士、注册会计师、注册税务师 浙江大学、中山大学总裁班特邀讲师 浙江省企业培训师协会副会长 国家人力资源管理师一级辅导师 曾任美国Bel Fuse Inc.中国区人力资源经理、财务总监 曾任世界500强人力资源总监、财务总监 国内人力资源与财务管理结合专家 个人经历: 具有近20年的HR、财务、税务、投行、资本运作等从业经验,曾服务于世界500强企业及中国民营500强企业;熟悉跨国公司与民营企业管理的规律与特点。是业内不多的能同时把人力资源与财务、投行有效结合起来的专家。 熟悉私募基金运营、资本运作、投融资、股权融资、收购兼并。参与并主导多家企业的IPO(主板与新三板)上市工作,并积累丰富的投行经验。 原创性提出私募基金在合伙人制度当中的运用,HR效能方式方程式等思路与模式。他在多年HR和财务工作实践经验中总结提炼而成的《合伙人制度》、《人力资源效能方程式》、《非财务经理的财务管理》课程多次面向社会开设公开课,获得学员高度认可和广泛运用。 主讲课程: 《合伙人制度》《人力资源效能方程式》《HR如何有效支持业务伙伴》《非财务经理的财务管理》《绩效管理实操及落地提升》《人力资源经理的财务管理》《绩效平衡与落地》《基于smart原理的薪酬体系设计》 服务客户: 蒙牛集团、青岛啤酒、玖龙纸业、比亚迪、中国招商银行、中国银行、中国农业银行、中国电信、中国移动、中国联通、中国邮政、统一食品、天狮集团、蒙牛集团、稻花香集团、洋河酒业、古越龙山酒业、银基集团、双汇集团、贝因美奶粉、雅士利涂料、青岛啤酒、蓝带啤酒、隆力奇、伊利乳业、河南宝丰酒业、今麦郎饮品、大用食品、广东嘉士利食品、步森集团、上海紫燕食品有限公司等 家电、电器:宁波奥克斯集团、现代联合集团、东芝集团、美的集团、华润集团、联想集团、TCL集团、美菱电器、老板电器、先锋电器、华科家电、广东小太阳电器、明泰手机、中航油、佳通轮胎(新加坡)、杭州齿轮箱集团、江苏正大天晴药业、厦门中药厂、北京正安医疗设备、马应龙药业、博莱药业、九福集团、嘉欧化妆品、吉亨药业、南阳汇博、上海大众、吉利集团、东风汽车集团、中通汽车工业集团、长林机械厂、千里马工程机械等 。 2017/5/4 星期四16:46:14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1649634 at bugs.launchpad.net Sun May 14 04:26:58 2017 From: 1649634 at bugs.launchpad.net (OpenStack Infra) Date: Sun, 14 May 2017 04:26:58 -0000 Subject: [Openstack-security] [Bug 1649634] Re: Insecure Randomness for AES Passphrase Generation References: <20161213164942.27372.15759.malonedeb@chaenomeles.canonical.com> Message-ID: <149473602137.8899.4559915383196703127.launchpad@wampee.canonical.com> ** Changed in: cinder Assignee: Rohan Arora (ra271w) => Tin Lam (tl3438) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1649634 Title: Insecure Randomness for AES Passphrase Generation Status in Cinder: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: In cinder/volume/drivers/synology/synology_common.py:176 in function _random_AES_passpharse() (sic) randint is used to generate an index that is used to select which character is added to the AES key. However, this is insecure and is stated in the Python documentation where they write "The pseudo-random generators of this module should not be used for security purposes." They recommend instead using os.urandom() or SystemRandom if a cryptographically secure prng is required. The proposed fix would be to simply be to use SystemRandom as it has all of the same functions from random implemented and does not require any new libraries. Another option is to use the Crypto library which is already imported in the file. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1649634/+subscriptions From 1686110 at bugs.launchpad.net Thu May 18 08:04:32 2017 From: 1686110 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 18 May 2017 08:04:32 -0000 Subject: [Openstack-security] [Bug 1686110] Re: AIDE configuration is set AFTER the initial run References: <20170425143229.16670.26982.malonedeb@wampee.canonical.com> Message-ID: <149509467217.7927.2949876845211209800.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/459719 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=1819c4241a6b12de4119d1f5ec1b75451f64789c Submitter: Jenkins Branch: master commit 1819c4241a6b12de4119d1f5ec1b75451f64789c Author: Major Hayden Date: Tue May 16 10:32:13 2017 -0500 Configure AIDE before initial run This patch ensures that AIDE is fully configured before the first database initialization process begins. Closes-Bug: 1686110 Change-Id: I209b88afb305828fa6e46de255ef11f5a6645427 ** Changed in: openstack-ansible Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1686110 Title: AIDE configuration is set AFTER the initial run Status in openstack-ansible: Fix Released Bug description: The "Configure AIDE to verify additional properties" task runs *after* the tasks which do the AIDE initialization. This isn't a problem on CentOS since the default properties meet the STIG requirements, but it does affect Ubuntu. The result is that Ubuntu users may see a huge AIDE update upon their second AIDE run. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1686110/+subscriptions From 1686110 at bugs.launchpad.net Thu May 18 13:28:04 2017 From: 1686110 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 18 May 2017 13:28:04 -0000 Subject: [Openstack-security] [Bug 1686110] Fix proposed to openstack-ansible-security (stable/ocata) References: <20170425143229.16670.26982.malonedeb@wampee.canonical.com> Message-ID: <149511408426.12972.11201228269827651303.malone@gac.canonical.com> Fix proposed to branch: stable/ocata Review: https://review.openstack.org/465967 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1686110 Title: AIDE configuration is set AFTER the initial run Status in openstack-ansible: Fix Released Bug description: The "Configure AIDE to verify additional properties" task runs *after* the tasks which do the AIDE initialization. This isn't a problem on CentOS since the default properties meet the STIG requirements, but it does affect Ubuntu. The result is that Ubuntu users may see a huge AIDE update upon their second AIDE run. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1686110/+subscriptions From 1686110 at bugs.launchpad.net Thu May 18 14:50:05 2017 From: 1686110 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 18 May 2017 14:50:05 -0000 Subject: [Openstack-security] [Bug 1686110] Re: AIDE configuration is set AFTER the initial run References: <20170425143229.16670.26982.malonedeb@wampee.canonical.com> Message-ID: <149511900529.12634.9614991782739179268.malone@gac.canonical.com> Reviewed: https://review.openstack.org/465967 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=7db180f80184260aebac5c4df06c31930086b751 Submitter: Jenkins Branch: stable/ocata commit 7db180f80184260aebac5c4df06c31930086b751 Author: Major Hayden Date: Tue May 16 10:32:13 2017 -0500 Configure AIDE before initial run This patch ensures that AIDE is fully configured before the first database initialization process begins. Manual backport of I209b88afb305828fa6e46de255ef11f5a6645427 was required due to the STIG renaming done in Pike. Change-Id: I41c65e16b61721fecb2aac2251126ce21d7a4353 Closes-Bug: 1686110 ** Tags added: in-stable-ocata -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1686110 Title: AIDE configuration is set AFTER the initial run Status in openstack-ansible: Fix Released Bug description: The "Configure AIDE to verify additional properties" task runs *after* the tasks which do the AIDE initialization. This isn't a problem on CentOS since the default properties meet the STIG requirements, but it does affect Ubuntu. The result is that Ubuntu users may see a huge AIDE update upon their second AIDE run. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1686110/+subscriptions From 1668503 at bugs.launchpad.net Fri May 19 00:38:38 2017 From: 1668503 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 19 May 2017 00:38:38 -0000 Subject: [Openstack-security] [Bug 1668503] Re: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing References: <20170228052347.7890.80677.malonedeb@chaenomeles.canonical.com> Message-ID: <149515432059.12615.16179032655429985643.launchpad@wampee.canonical.com> ** Changed in: keystone Assignee: Morgan Fainberg (mdrnstm) => Gage Hugo (gagehugo) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1668503 Title: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) mitaka series: Won't Fix Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: Won't Fix Status in OpenStack Identity (keystone) pike series: In Progress Status in OpenStack Security Advisory: Incomplete Bug description: Keystone uses sha512_crypt for password hashing. This is insufficient and provides limited protection (even with 10,000 rounds) against brute-forcing of the password hashes (especially with FPGAs and/or GPU processing). The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt. This bug is marked as public security as bug #1543048 has already highlighted this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions From 1543048 at bugs.launchpad.net Fri May 19 00:38:32 2017 From: 1543048 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 19 May 2017 00:38:32 -0000 Subject: [Openstack-security] [Bug 1543048] Re: support alternative password hashing in keystone References: <20160208102502.15773.89678.malonedeb@gac.canonical.com> Message-ID: <149515431729.11521.159992120798178685.launchpad@soybean.canonical.com> ** Changed in: keystone Assignee: Morgan Fainberg (mdrnstm) => Gage Hugo (gagehugo) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1543048 Title: support alternative password hashing in keystone Status in OpenStack Identity (keystone): In Progress Bug description: Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt. NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost. The proposal is as follows: * Allow selected support of different password hashing algorithms from with passlib architecturally * Expand to support bcrypt * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12 * Keep the default the same as today * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required) * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1543048/+subscriptions From gagehugo at gmail.com Fri May 19 00:50:50 2017 From: gagehugo at gmail.com (Gage Hugo) Date: Fri, 19 May 2017 00:50:50 -0000 Subject: [Openstack-security] [Bug 1543048] Re: support alternative password hashing in keystone References: <20160208102502.15773.89678.malonedeb@gac.canonical.com> Message-ID: <149515505231.12157.15728308654165571247.launchpad@soybean.canonical.com> ** Changed in: keystone Assignee: Gage Hugo (gagehugo) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1543048 Title: support alternative password hashing in keystone Status in OpenStack Identity (keystone): In Progress Bug description: Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt. NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost. The proposal is as follows: * Allow selected support of different password hashing algorithms from with passlib architecturally * Expand to support bcrypt * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12 * Keep the default the same as today * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required) * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1543048/+subscriptions From 1543048 at bugs.launchpad.net Fri May 19 01:03:51 2017 From: 1543048 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 19 May 2017 01:03:51 -0000 Subject: [Openstack-security] [Bug 1543048] Re: support alternative password hashing in keystone References: <20160208102502.15773.89678.malonedeb@gac.canonical.com> Message-ID: <149515583357.12400.15162519388055573298.launchpad@soybean.canonical.com> ** Changed in: keystone Assignee: (unassigned) => Gage Hugo (gagehugo) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1543048 Title: support alternative password hashing in keystone Status in OpenStack Identity (keystone): In Progress Bug description: Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt. NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost. The proposal is as follows: * Allow selected support of different password hashing algorithms from with passlib architecturally * Expand to support bcrypt * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12 * Keep the default the same as today * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required) * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1543048/+subscriptions From lbragstad at gmail.com Fri May 19 14:25:21 2017 From: lbragstad at gmail.com (Lance Bragstad) Date: Fri, 19 May 2017 14:25:21 -0000 Subject: [Openstack-security] [Bug 1668503] Re: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing References: <20170228052347.7890.80677.malonedeb@chaenomeles.canonical.com> Message-ID: <149520392270.6410.1746614253435821454.launchpad@chaenomeles.canonical.com> ** Changed in: keystone/pike Assignee: Gage Hugo (gagehugo) => (unassigned) ** Changed in: keystone/pike Assignee: (unassigned) => Morgan Fainberg (mdrnstm) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1668503 Title: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) mitaka series: Won't Fix Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: Won't Fix Status in OpenStack Identity (keystone) pike series: In Progress Status in OpenStack Security Advisory: Incomplete Bug description: Keystone uses sha512_crypt for password hashing. This is insufficient and provides limited protection (even with 10,000 rounds) against brute-forcing of the password hashes (especially with FPGAs and/or GPU processing). The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt. This bug is marked as public security as bug #1543048 has already highlighted this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions From lbragstad at gmail.com Fri May 19 14:25:00 2017 From: lbragstad at gmail.com (Lance Bragstad) Date: Fri, 19 May 2017 14:25:00 -0000 Subject: [Openstack-security] [Bug 1543048] Re: support alternative password hashing in keystone References: <20160208102502.15773.89678.malonedeb@gac.canonical.com> Message-ID: <149520390132.12451.2055152874076580862.launchpad@gac.canonical.com> ** Changed in: keystone Assignee: Gage Hugo (gagehugo) => (unassigned) ** Changed in: keystone Assignee: (unassigned) => Morgan Fainberg (mdrnstm) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1543048 Title: support alternative password hashing in keystone Status in OpenStack Identity (keystone): In Progress Bug description: Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt. NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost. The proposal is as follows: * Allow selected support of different password hashing algorithms from with passlib architecturally * Expand to support bcrypt * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12 * Keep the default the same as today * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required) * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1543048/+subscriptions From fungi at yuggoth.org Sun May 21 13:11:16 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Sun, 21 May 2017 13:11:16 -0000 Subject: [Openstack-security] [Bug 1685678] Re: swap volume operation may leak credentials into debug logs References: <20170424003200.1328.91704.malonedeb@gac.canonical.com> Message-ID: <149537227668.12267.2462509742016771302.launchpad@gac.canonical.com> ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - - -- - The swap volume code in the compute service logs old and new volume connection_info dicts to debug here: https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4930 The new connection_info comes from Cinder: https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4901 That's a plain dict from the response which may contain credentials. The old connection_info comes from the nova.objects.block_device.BlockDeviceMapping object, which uses SensitiveStringField to sanitize the field's value when logged: https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4904 https://github.com/openstack/oslo.versionedobjects/blob/1.23.0/oslo_versionedobjects/fields.py#L280 The new connection_info could contain credentials though, so we should mask those when logging it, even at debug level. ** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1685678 Title: swap volume operation may leak credentials into debug logs Status in OpenStack Compute (nova): Triaged Status in OpenStack Security Advisory: Won't Fix Bug description: The swap volume code in the compute service logs old and new volume connection_info dicts to debug here: https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4930 The new connection_info comes from Cinder: https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4901 That's a plain dict from the response which may contain credentials. The old connection_info comes from the nova.objects.block_device.BlockDeviceMapping object, which uses SensitiveStringField to sanitize the field's value when logged: https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4904 https://github.com/openstack/oslo.versionedobjects/blob/1.23.0/oslo_versionedobjects/fields.py#L280 The new connection_info could contain credentials though, so we should mask those when logging it, even at debug level. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1685678/+subscriptions From 1685678 at bugs.launchpad.net Sun May 21 13:33:05 2017 From: 1685678 at bugs.launchpad.net (OpenStack Infra) Date: Sun, 21 May 2017 13:33:05 -0000 Subject: [Openstack-security] [Bug 1685678] Re: swap volume operation may leak credentials into debug logs References: <20170424003200.1328.91704.malonedeb@gac.canonical.com> Message-ID: <149537358548.11966.16642816954219780900.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/466533 ** Changed in: nova Status: Triaged => In Progress ** Changed in: nova Assignee: (unassigned) => Matt Riedemann (mriedem) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1685678 Title: swap volume operation may leak credentials into debug logs Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: The swap volume code in the compute service logs old and new volume connection_info dicts to debug here: https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4930 The new connection_info comes from Cinder: https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4901 That's a plain dict from the response which may contain credentials. The old connection_info comes from the nova.objects.block_device.BlockDeviceMapping object, which uses SensitiveStringField to sanitize the field's value when logged: https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4904 https://github.com/openstack/oslo.versionedobjects/blob/1.23.0/oslo_versionedobjects/fields.py#L280 The new connection_info could contain credentials though, so we should mask those when logging it, even at debug level. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1685678/+subscriptions From fungi at yuggoth.org Wed May 24 14:29:21 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 24 May 2017 14:29:21 -0000 Subject: [Openstack-security] [Bug 1651679] Re: horizon auth switch redir DoS References: <20161221083443.14341.14434.malonedeb@wampee.canonical.com> Message-ID: <149563616149.17490.2204589990593847545.malone@chaenomeles.canonical.com> There's been no input whatsoever from Horizon devs, but since the reporter already seems to have agreed in comment #7 and this has been open for over 5 months now let's just press forward. ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - - -- - It is possible to construct URLs and embed them in unrelated websites like this and when a logged-in user loads such a page (tested with Firefox), it generates load on the horizon server without being visible to the user. I addition to the SSL overhead, this also creates one token per redirect. In Liberty this token was immediately revoked and in Newton it is not (so IMHO even worse). This can slow the DB down until tokens expire and cron runs again su keystone -s /bin/bash -c "/usr/bin/keystone-manage --config-file /etc/keystone/keystone.conf token_flush" || : ** Information type changed from Private Security to Public ** Tags added: security ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1651679 Title: horizon auth switch redir DoS Status in django-openstack-auth: New Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisory: Won't Fix Bug description: It is possible to construct URLs and embed them in unrelated websites like this and when a logged-in user loads such a page (tested with Firefox), it generates load on the horizon server without being visible to the user. I addition to the SSL overhead, this also creates one token per redirect. In Liberty this token was immediately revoked and in Newton it is not (so IMHO even worse). This can slow the DB down until tokens expire and cron runs again su keystone -s /bin/bash -c "/usr/bin/keystone-manage --config-file /etc/keystone/keystone.conf token_flush" || : To manage notifications about this bug go to: https://bugs.launchpad.net/django-openstack-auth/+bug/1651679/+subscriptions From fungi at yuggoth.org Wed May 24 14:38:41 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 24 May 2017 14:38:41 -0000 Subject: [Openstack-security] [Bug 1687018] Re: One can request to put a volume next to any tenant's instance via InstanceLocalityFilter References: <20170428131109.26812.46087.malonedeb@gac.canonical.com> Message-ID: <149563672093.17459.15528705395096462121.malone@chaenomeles.canonical.com> Consensus already seems to have been reached that this is not a vulnerability, so I'm going to open it publicly as a hardening opportunity. ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - During working on bug #1686616, I realized that using the privileged user to find the host for an instance works for any other projects, even if the requesting user doesn't have rights to see other projects' instances. I guess it is not a big impact, one has to know an UUID of a foreign instance, and the maximum effect is to put a volume on the host where the instance resides (if it has a cinder-volume running). I think after the filter gets the server info via the privileged user, it must check if it has rights to access that info. If a privileged user is not configured, there's no problem. ** Information type changed from Private Security to Public ** Tags added: security ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1687018 Title: One can request to put a volume next to any tenant's instance via InstanceLocalityFilter Status in Cinder: New Status in OpenStack Security Advisory: Won't Fix Bug description: During working on bug #1686616, I realized that using the privileged user to find the host for an instance works for any other projects, even if the requesting user doesn't have rights to see other projects' instances. I guess it is not a big impact, one has to know an UUID of a foreign instance, and the maximum effect is to put a volume on the host where the instance resides (if it has a cinder-volume running). I think after the filter gets the server info via the privileged user, it must check if it has rights to access that info. If a privileged user is not configured, there's no problem. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1687018/+subscriptions From fungi at yuggoth.org Wed May 24 14:36:22 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 24 May 2017 14:36:22 -0000 Subject: [Openstack-security] [Bug 1681465] Re: VNC connection to VMs is unprotected References: <20170410144043.30866.56391.malonedeb@soybean.canonical.com> Message-ID: <149563658235.17705.3037004060469971993.malone@chaenomeles.canonical.com> I really don't see where keeping this report secret is helping anyone anyway, and given that the risk for this is already documented and there is known work underway to mitigate it in future releases I'm going ahead with switching it to public, as a potential hardening opportunity. ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - Description: ============ OpenStack Nova does not provide any protection of VNC servers running on compute nodes by default. Any client that has access to management network can connect to the consoles of VMs running on compute node and obtains full access to VMs via the console (e.g. by rebooting VMs to single-user mode). Steps to reproduce ================== - Configuration: the management interface of the compute node has a public IP address and is not protected by firewalls - Create a VM on the compute node - Use a VNC client to connect directly to the IP of the compute node via port 590x from anywhere. Expected result =============== Connections refused. Only VNC connections from master node should be accepted. Other should connect using proxy on master node which does also authorization Actual result ============= Connection accepted. Anyone can use VNC client to connect directly to the console of VMs running on the compute node without any authentication/authorization Discussion =========== To be fair, most of examples in the OpenStack documentation have management networks private, so the network configuration in the examples are safe. However, OpenStack documentation only emphasizes the separation of management network from other networks (VM, data) and does not explicitly require (in a visible way) that the management networks must be protected (private networks, firewalls). The management network may be separated to another (public) network segment and the system is still vulnerable to the VNC attack. Therefore, the VNC connection to compute nodes should be protected (password, iptables) by default, or the documentation should give explicit warning that the management network must be private or protected by firewalls. ** Information type changed from Private Security to Public ** Tags added: security ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1681465 Title: VNC connection to VMs is unprotected Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Won't Fix Bug description: Description: ============ OpenStack Nova does not provide any protection of VNC servers running on compute nodes by default. Any client that has access to management network can connect to the consoles of VMs running on compute node and obtains full access to VMs via the console (e.g. by rebooting VMs to single-user mode). Steps to reproduce ================== - Configuration: the management interface of the compute node has a public IP address and is not protected by firewalls - Create a VM on the compute node - Use a VNC client to connect directly to the IP of the compute node via port 590x from anywhere. Expected result =============== Connections refused. Only VNC connections from master node should be accepted. Other should connect using proxy on master node which does also authorization Actual result ============= Connection accepted. Anyone can use VNC client to connect directly to the console of VMs running on the compute node without any authentication/authorization Discussion =========== To be fair, most of examples in the OpenStack documentation have management networks private, so the network configuration in the examples are safe. However, OpenStack documentation only emphasizes the separation of management network from other networks (VM, data) and does not explicitly require (in a visible way) that the management networks must be protected (private networks, firewalls). The management network may be separated to another (public) network segment and the system is still vulnerable to the VNC attack. Therefore, the VNC connection to compute nodes should be protected (password, iptables) by default, or the documentation should give explicit warning that the management network must be private or protected by firewalls. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1681465/+subscriptions From fungi at yuggoth.org Wed May 24 14:32:09 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 24 May 2017 14:32:09 -0000 Subject: [Openstack-security] [Bug 1657139] Re: XML Injection References: <20170117144110.27439.8124.malonedeb@chaenomeles.canonical.com> Message-ID: <149563632960.24715.12496942978998460784.launchpad@soybean.canonical.com> ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - The xml.dom.minidom module is not secure against maliciously constructed data. If you need to parse untrusted or unauthenticated data see XML vulnerabilities. Trove code base is using xml.dom.minidom. Writing unvalidated data into an XML document can allow an attacker to change the structure and contents of the XML. https://github.com/openstack/trove/blob/129fac7d5374e18a428afa1b5c0259743677222e/trove/common/base_wsgi.py#L509 ** Information type changed from Private Security to Public ** Tags added: security ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1657139 Title: XML Injection Status in OpenStack Security Advisory: Won't Fix Status in OpenStack DBaaS (Trove): New Bug description: The xml.dom.minidom module is not secure against maliciously constructed data. If you need to parse untrusted or unauthenticated data see XML vulnerabilities. Trove code base is using xml.dom.minidom. Writing unvalidated data into an XML document can allow an attacker to change the structure and contents of the XML. https://github.com/openstack/trove/blob/129fac7d5374e18a428afa1b5c0259743677222e/trove/common/base_wsgi.py#L509 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1657139/+subscriptions From major at mhtx.net Wed May 24 19:47:21 2017 From: major at mhtx.net (Major Hayden) Date: Wed, 24 May 2017 19:47:21 -0000 Subject: [Openstack-security] [Bug 1693343] [NEW] V-71945 fails on CentOS 7 Message-ID: <149565524123.24782.9127842748680337701.malonedeb@soybean.canonical.com> Public bug reported: 2017-05-24 17:35:21.290912 | TASK [openstack-ansible-security : V-71945 - If three unsuccessful logon attempts within 15 minutes occur the associated account must be locked.] *** 2017-05-24 17:35:21.312253 | Wednesday 24 May 2017 17:35:21 +0000 (0:00:00.320) 0:00:19.083 ********* 2017-05-24 17:35:21.468598 | fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "Path pam_password_file does not exist !", "rc": 257} ** Affects: openstack-ansible Importance: Low Assignee: Major Hayden (rackerhacker) Status: In Progress ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1693343 Title: V-71945 fails on CentOS 7 Status in openstack-ansible: In Progress Bug description: 2017-05-24 17:35:21.290912 | TASK [openstack-ansible-security : V-71945 - If three unsuccessful logon attempts within 15 minutes occur the associated account must be locked.] *** 2017-05-24 17:35:21.312253 | Wednesday 24 May 2017 17:35:21 +0000 (0:00:00.320) 0:00:19.083 ********* 2017-05-24 17:35:21.468598 | fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "Path pam_password_file does not exist !", "rc": 257} To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1693343/+subscriptions From 1693343 at bugs.launchpad.net Wed May 24 19:51:13 2017 From: 1693343 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 24 May 2017 19:51:13 -0000 Subject: [Openstack-security] [Bug 1693343] Re: V-71945 fails on CentOS 7 References: <149565524123.24782.9127842748680337701.malonedeb@soybean.canonical.com> Message-ID: <149565547323.2833.16448799916545290987.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/467738 ** Changed in: openstack-ansible Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1693343 Title: V-71945 fails on CentOS 7 Status in openstack-ansible: In Progress Bug description: 2017-05-24 17:35:21.290912 | TASK [openstack-ansible-security : V-71945 - If three unsuccessful logon attempts within 15 minutes occur the associated account must be locked.] *** 2017-05-24 17:35:21.312253 | Wednesday 24 May 2017 17:35:21 +0000 (0:00:00.320) 0:00:19.083 ********* 2017-05-24 17:35:21.468598 | fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "Path pam_password_file does not exist !", "rc": 257} To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1693343/+subscriptions From 1693343 at bugs.launchpad.net Thu May 25 15:04:19 2017 From: 1693343 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 25 May 2017 15:04:19 -0000 Subject: [Openstack-security] [Bug 1693343] Re: V-71945 fails on CentOS 7 References: <149565524123.24782.9127842748680337701.malonedeb@soybean.canonical.com> Message-ID: <149572465914.23334.5651998539118752295.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/467738 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=d7600f1a12f655e9136c1a2bfa102b6f47e0e198 Submitter: Jenkins Branch: master commit d7600f1a12f655e9136c1a2bfa102b6f47e0e198 Author: Major Hayden Date: Wed May 24 14:50:19 2017 -0500 Fix bare jinja variable pam_password_file The pam_password_variable didn't have jinja tags around it and it wasn't being handled correctly. This patch fixes the bug and makes the task name easier to read. Closes-Bug: 1693343 Change-Id: Ie469c32a71c3c0e1b381739290ffb608bb04a21c ** Changed in: openstack-ansible Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1693343 Title: V-71945 fails on CentOS 7 Status in openstack-ansible: Fix Released Bug description: 2017-05-24 17:35:21.290912 | TASK [openstack-ansible-security : V-71945 - If three unsuccessful logon attempts within 15 minutes occur the associated account must be locked.] *** 2017-05-24 17:35:21.312253 | Wednesday 24 May 2017 17:35:21 +0000 (0:00:00.320) 0:00:19.083 ********* 2017-05-24 17:35:21.468598 | fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "Path pam_password_file does not exist !", "rc": 257} To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1693343/+subscriptions From gerrit2 at review.openstack.org Fri May 26 16:28:40 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 26 May 2017 16:28:40 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I4cc3fd9e0958c3f7fda83ad696807a7c8f63cecb Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/401808 Log: commit 592323f85b32d02421a9107f93bda7a407d03b0b Author: Adam Young Date: Thu Nov 3 20:13:07 2016 -0400 Route based RBAC Management Interface A new entity in the Role backend that maps from VERB + Path to Role. I.E. from GET /v2/users to Member Beyond the backend and CRUD API for Routes there is also a Bulk Upload and management API. No RBAC enforcement is done in this commit, just management of the data that will be used in Keystone middleware. blueprint token-verify-role-check SecurityImpact APIImpact Co-Authored-By: Kristi Nikolla Change-Id: I4cc3fd9e0958c3f7fda83ad696807a7c8f63cecb From gerrit2 at review.openstack.org Tue May 30 15:40:09 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 30 May 2017 15:40:09 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I4cc3fd9e0958c3f7fda83ad696807a7c8f63cecb Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/401808 Log: commit 4b3b324341edc624ad2c5b283da982c11b95b4a5 Author: Adam Young Date: Thu Nov 3 20:13:07 2016 -0400 Route based RBAC Management Interface A new entity in the Role backend that maps from VERB + Path to Role. I.E. from GET /v2/users to Member Beyond the backend and CRUD API for Routes there is also a Bulk Upload and management API. No RBAC enforcement is done in this commit, just management of the data that will be used in Keystone middleware. blueprint token-verify-role-check SecurityImpact APIImpact Co-Authored-By: Kristi Nikolla Change-Id: I4cc3fd9e0958c3f7fda83ad696807a7c8f63cecb