3.0.5 and Xen API security

3.0.5 and Xen API security

[John Levon]

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.

However, I'm aware that setting this up isn't always wanted (indeed, I
don't have the slightest idea how to do that myself). You might want to
use HTTPS as merely a secure transport. Today, that's a big security
hole.

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.

I don't think it makes sense to ship anything other than the certificate
based solution until something is hashed out here.

On Solaris, I think we'd have a simple PAM module that checked the user
had the right RBAC profile.

regards
john

Re: 3.0.5 and Xen API security

[Daniel P. Berrange]

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  -=| 

Re: 3.0.5 and Xen API security

[Stefan Berger]

[-- Attachment #1.1: Type: text/plain, Size: 1780 bytes --]

xen-devel-bounces@lists.xensource.com wrote on 04/20/2007 01:22:45 PM:

> 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.
> > 
> 
> > 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.

The xen-api has a class user that probably was meant for this purpose. 
There could be a 'sysadmin' user with a default password or the root 
password preinstalled on a system.
It looks like the record of a user should be extended with a (write-only) 
password field and maybe a change_password() method.

   Stefan 

> 
> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 2379 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel