Re: [Xen-API] Use of PAM for authentication & SSL comms

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Wed, Nov 01, 2006 at 11:57:27AM +0000, Ewan Mellor wrote:
> On Wed, Nov 01, 2006 at 11:38:47AM +0000, Alastair Tse wrote:
> 
> > > - XenD should install its own PAM config file into /etc/pam.d
> > >   rather than re-using the context from the 'login' program
> > 
> > 
> > Well, the problem I ran into is that every distro has their own  
> > custom PAM stack and any PAM stack we write will only work on one  
> > distro and not another. I believe this is a distro packaging problem.  
> > But your concern is still valid, maybe we have to provide a PAM stack  
> > for one at least one distro. Let's fight to see which one that will  
> > be :)
> 
> Back off, Gentoo-freak ;-)

I was about to suggest we pick a PAM config which matches those
distirbuted by upstream Linux-PAM codebase, but it appears they
don't distribute any example configs leaving that job to vendors

> > > - If we're using PAM then we must switch all communications to use
> > >   SSL by default - no network daemon should be using system
> > >   passwords over a cleartext network channel anymore. If we want
> > >   to keep a cleartext channel, then we should use a separate
> > >   password database & certainly not system logins
> > 
> > Definitely. I've only been testing with a local UNIX domain socket.  
> > Anything that goes over the network needs SSL encryption, but the API  
> > docs don't make any mention of this, presumably because it doesn't  
> > really fall into the API.
> 
> Actually, I agreed at the last Xen Summit that we would add a list of
> supported transports to that API document.  The intention is that any server
> meeting the spec can talk to any client meeting the spec, so of course we need
> a list of supported transports too.
> 
> This list is something we need to write down -- HTTP/local, HTTP/TCP,
> HTTP/SSL/TCP are the obvious ones, but if someone needs something else, it's
> still open to discussion.

Yes, that sounds like a good set required for a minimally compliant client
implementation to talk. We'll also likely want to support the TCP listeners
on both IPv4 & IPv6 in the near future. In Fedora & RHEL its now policy
to have all network apps suppport IPv4 & IPv6 connections enabled  by
default upon install, so if you don't get it into initial codebase I'll
probably find myself submitting a patch shortly thereafter :-)

> 
> > My guess is we'll need to put some  
> > certificate configuration options in xend-config.sxp or run the Xen  
> > API on a different XMLRPC server than the one that currently serves xm.
> 
> Yeah, I think that we're certainly going to need to use a different port, even
> if we're using the same dispatcher behind that.  I'm not sure what to do about
> certificate management -- any suggestions?

I've never done it in pure python before, but a quick google suggests the
pyopenssl binding is the thing we want. There is a SSL.Connection object
for dealing with the socket stuff & SSL.Context for certificate side of
things.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api