[Xen-devel] 3.0.5 and Xen API security

[John Levon <levon@xxxxxxxxxxxxxxxxx>]

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

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