openstack-ossg team mailing list archive

[Adam Young <ayoung@xxxxxxxxxx>]

On 10/26/2012 02:49 PM, Bryan D. Payne wrote:
> Adam,
>
> Thanks for bringing this to our attention.  I've asked Paul M from
> Nebula (cc'd) to take a look at this.  First blush is that it may have
> some problems.  Paul is an expert on web security and will most
> certainly have some thoughts to provide.  Given the nature of the
> patch and the existing discussion, it will take him some time to get
> up to speed.  He is hoping to get some feedback posted later today.
>
> Cheers,
> -bryan

Thanks, Bryan.

Paul: to give a little more context: we are using a web server called 
Eventlet:
http://www.eventlet.net/

It is a single threaded, continuations based web server that uses the 
greenlet library:
http://pypi.python.org/pypi/greenlet

It does not support any form of authentication.  The patch is not for 
default Keystone running in Eventlet, but rather for:  Migrating over to 
run in Apache HTTPD
or adding additional middleware into Eventlet to perform some form of 
basic-auth or more secure form of authentication in the future.



> On Thu, Oct 25, 2012 at 1:28 PM, Adam Young <ayoung@xxxxxxxxxx> wrote:
> > https://review.openstack.org/#/c/14823/
> >
> > There are a lot of features that come with running in HTTPD.  The above
> > patch is essential to HTTPD support, specificially for Keystone.
> >
> > There has been some discussion about disabling REMOTE_USER via a config file
> > option by default, but I think that is neither necessary nor sufficient. If
> > using container based authentication has a security issue, we should be
> > aware of it up front.  If it is not, a config file will just frustrate
> > people trying to set up remote authentication.  REMOTE_USER should become
> > the default method of authentication in the future anyway, as it is the
> > direct tie in with the HTTP spec.  Using Kerberos or PKI is dependant on
> > this change. As such, it should be improving security, not lessening it.
> >
> > As far as I have found, there is no way that a malicious user can affect the
> > env var dictionary to falsely inject REMOTE_USER.
> >
> > All headers that get set and passed in get modified such that they end up in
> > the environment with 'HTTP_ ' prepended
> > Args passed to GET and post URLS, as well as cookies, go into internal
> > collections, and do not show up in the top level dictionary.
> >
> >
> >
> > --
> > Mailing list: https://launchpad.net/~openstack-ossg
> > Post to     : openstack-ossg@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack-ossg
> > More help   : https://help.launchpad.net/ListHelp