On Fri, Apr 20, 2007 at 05:20:15PM +0100, John Levon wrote:
>
> I talked with Ewan about this a little bit, but thinking some more it
> seems like we really need to resolve this before 3.0.5.
>
> Currently, if you're not using some other method, then to have full
> control over xend a user needs only:
>
> 1) to be able to connect to a xen api listener
> 2) to be able to login to the machine
>
> The latter is because xend is hijacking the 'login' service of PAM.
> Ewan's already agreed we need to change this to use a separate service,
> but I think this really needs fixing now.
>
> I don't know anything about SSL, but I /presume/ that the code we have
> for private key/certificates is sufficient for checking a client's
> certificates and permissions (though Dan Berrange suggested to me this
> might not be the case). Thus in this configuration, this will form
> the authentication barrier.
There are several ways to use SSL. The default way doesn't do any
certificate authentication. The server will provide its certificate
to the client, so the client can check the server's authenticity
against its trusted CA certs. This is the way pretty much all web
sites/browsers operate. If you want to use x509 for authentication
then, you need to set an option on the server to make it request a
x509 certificate from the client. The server can then verify the
client's cert against its own CA cert.
If it stops there, the server will be allowing access to any client
with a cert signed by one of its trusted CAs. For this to make sense,
your organization very likely wants to be using its own internal CA,
and adding a separate auth process (like PAM) ontop.
If you want to rely solely on mutual x509 cert verification as the
auth method, then server will also wants to maintain a whitelist of
client certs which it accepts. It would typically key off the common
name field in the cert.
The current code in XenD that I see does
ctx = SSL.Context(SSL.SSLv23_METHOD)
ctx.set_options(SSL.OP_NO_SSLv2)
ctx.use_privatekey_file (ssl_key_file)
ctx.use_certificate_file(ssl_cert_file)
Which merely sets up the default SSL context. This doesn't enable
any form of client certificate verification in the server end. So
XenD definitely still needs an additional (PAM) auth layer on top
of this.
If we wanted to have the server do client cert verification then
we'd need to call the ctx.set_verify() method, passing in the
VERIFY_PEER & VERIFY_FAIL_IF_NO_PEER_CERT constants. It would also
need to supply a callback to do things like checking the certificate
validity & expiration dates, and applying its whitelist,e tc.
> We need to change xend to use the 'xend' service, and deliver an
> /etc/pam.d/xend file. Since there is no infrastructure yet for deciding
> if a user can control xend, it seems like this should always refuse
> authentication unless the certificate stuff has verified correctly. Or
> at least we must actively disable connections except over the unix
> socket or authenticated SSL.
The question when using PAM is really what user database are we authenticating
against ? Do we auth against 'root', or any local user, or a completely
separate list of users. I'd really imagine the latter, since places may
well want to separate the general sysadmin role, from the XenD management
roles.
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-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home