Mailing List Archive: Use of PAM for authentication & SSL comms

I'm not had much time to actually try the new Xen-API work yet, so have
merely been reading the commits as the come in to keep track of work.
I wanted to raise the question of authentication. Changeset 77 in
the xen-api.hg branch switched Xen-API over to use PAM for authentication
of the remote logins.

http://xenbits.xensource.com/ext/xen-api.hg?cs=9bad549c20e3

This is very nice in principle, but I've a couple of thoughts about
the particular impl.

- The XML-RPC api is using a login method where you explicitly
pass in a username & password as the two params. This doesn't
really match up with the PAM model of conversation functions
which request one or more pieces of auth info in sequence. It
strikes me that since XML-RPC is a bi-directional protocol it
would make alot more sense to allow the PAM conversation callbacks
to go back & forth over the XML-RPC channel to collect data from
the client as needed, rather than having the client provide
the username & password ahead of time.

By removing the fixed user/passwd at the client end of the API
it'll be possible to add in support for all the different types
of auth people can configure with PAM. The obvious one being
kerberos GSSAPI single sign on.

- XenD should install its own PAM config file into /etc/pam.d
rather than re-using the context from the 'login' program

- 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

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api