Alex, You raise two issues, so let me address them independently.
First, you discuss protecting memcache for unauthorized access. Yes, this is something that every deployer of memcache (whether in conjunction with Swift or not) needs to consider. Unchecked access to memcache can allow information leaks and potentially cache poisoning. Memcache servers should be restricted in access to trusted clients. You describe one such way of doing so, and deployers will need to evaluate if your proposed method for themselves. I'd love to see you release the code around your SLIM implementation for Swift, but I do not think it should be in the Swift codebase. As to the code organization question, swift.common.memcached is a performant memcache client (note there are a couple of outstanding patches to improve this in various ways). swift.common.middleware.memcache is the cache middleware loaded by a Swift WSGI app, and it uses the library module for accessing the memcache pool. The memcache client is used by other middleware (eg ratelimit), so that's why it's in swift/common. The swift/common/middleware directory is for the modules that are available for a WSGI pipeline. (Note that swift.common.middleware.acl may be misplaced by this definition, but it's only used by tempauth.) I think the placement is right the way it is, and I don't think anything should move, especially since there potentially third party modules using these. --John On Sep 15, 2013, at 3:03 PM, Alexandra Shulman-Peleg <shulm...@il.ibm.com> wrote: > Hi, > > Following the declaration regarding the memcache vulnerability below, I > would like to raise a discussion regarding its protection. If we could > limit/control the access to memcache it would be easier to confine the > damage in case of an attack. For example, in the attached paper we added a > gatekeeper to ensure that the keys/values stored in the memcached of > Swift are accessed only by the tenant/domain to which they belong (e.g., a > user from domain A can not access the cached data of users belonging to > domain B), > > I suggest to provide a generic mechanism allowing insertion of various > memcache protections as dedicated middleware modules. Practically, > although in Swift we have a module memcache.py which is part of > middleware, the module memcached.py is located under "common". What is the > motivation for this code organization? Can we move the module memcached.py > to be under "middleware" in Swift? > > Thank you very much, > Alex. > > > > ---------------------------------------------------------- > Alexandra Shulman-Peleg, PhD > Storage Research, Cloud Platforms Dept. > IBM Haifa Research Lab > Tel: +972-3-7689530 | Fax: +972-3-7689545 > > > From: Thierry Carrez <thie...@openstack.org> > To: openstack-annou...@lists.openstack.org, > openst...@lists.openstack.org, > Date: 11/09/2013 06:52 PM > Subject: [Openstack] [OSSA 2013-025] Token revocation failure using > Keystone memcache/KVS backends (CVE-2013-4294) > > > > Signed PGP part > OpenStack Security Advisory: 2013-025 > CVE: CVE-2013-4294 > Date: September 11, 2013 > Title: Token revocation failure using Keystone memcache/KVS backends > Reporter: Kieran Spear (University of Melbourne) > Products: Keystone > Affects: Folsom, Grizzly > > Description: > Kieran Spear from the University of Melbourne reported a vulnerability > in Keystone memcache and KVS token backends. The PKI token revocation > lists stored the entire token instead of the token ID, triggering > comparison failures, ultimately resulting in revoked PKI tokens still > being considered valid. Only Folsom and Grizzly Keystone setups making > use of PKI tokens with the memcache or KVS token backends are affected. > Havana setups, setups using UUID tokens, or setups using PKI tokens with > the SQL token backend are all unaffected. > > Grizzly fix: > https://review.openstack.org/#/c/46080/ > > Folsom fix: > https://review.openstack.org/#/c/46079/ > > References: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4294 > https://bugs.launchpad.net/keystone/+bug/1202952 > > Regards, > > - -- > Thierry Carrez > OpenStack Vulnerability Management Team > > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openst...@lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > <multi-tenant-isolation.pdf>_______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
