Mailing List Archive

On Mon, Feb 05, 2007 at 02:28:54AM +0000, John Levon wrote:

>
> First off, I've never looked at PAM, and I probably have totally the wrong end
> of the stick.
>
> The API authorization uses the PAM 'login' stack. If I'm understanding things
> right, this means that any user/pass pair that matches /etc/passwd etc. will be
> able to log in. This seems really odd to me - why are matching up "can start a
> session in xend api" with "has a login account under the name services"? Given
> this doesn't provide meaningful authentication, what is the session intended
> for? Shouldn't we be using a new service name along with a pam_xendauth module
> or similar?

Yes, we almost certainly use a new service name; I'm not sure about a new
module. I would like to be able to say "the Xend service defers to this other
service" or "the Xend service only accepts the following users authenticated
using this other service". I've not had time to work on this -- patches would
certainly be appreciated.

> Of course there's no security layer above the XMLRPC defined either. AIUI
> you're still restricted to being root on the local machine or providing
> separate authorization over https.
>
> Imagine I wanted to delegate xend xml-rpc management to a local user on the
> machine (ignoring for now fine-grained control). I can't let normal users have
> permissions on the socket, since they can just get a session with their normal
> user/pass; I'd have to make them root.

You could write a very small setuid program that allowed access to the local
socket, or you could set-up sudo to allow similar things. You could defer to
SSH authentication, and handle it that way, or you could use stunnel in front
of Xend to protect the password on the wire.

These things haven't yet been integrated with Xend, but doing so is not very
hard. (In fact, Anthony Liguori has integrated SSH with xm for the legacy
protocols, though I'm not sure how much would be left to do to make that work
for the Xen-API too).

> Is this what
>
> "\item Delegation to the transport layer.
> \item Extend PAM exchange across the wire.
>
> is referring to in the TODO? Are there concrete plans on how this would work?

Item one refers to a stronger integration between Xend and the transport
layer, so that Xend could identify the user from the SSL authentication
exchange, for example.

Item two refers to an extension of the protocol so that you can perform the
PAM exchange all the way to the client. This may allow you to authenticate
using Kerberos rather than a username or password for example.

Neither of these things have concrete plans, nor as far as I am aware is
anyone working on them. They certainly aren't going to land for Xen-API 1.0
(though once again, patches are welcome).

> Is the session ID really cryptographically secure? The uuidgen man page worries
> me. Couldn't/shouldn't this creation of a session ID be delegated to a PAM
> module too?

We don't use uuidgen -- we randomly generate a 128 bit UUID, without the
time- or location- based aspect to the UUID that is possible with (some
versions of) uuidgen.

I think that 128 bits of randomness (using the non-secure RNG) is sufficient
for a short-lived session token such as this one. You wouldn't generate your
PGP keys like this, but for short-lived tokens it's fine.

> Finally, are there plans for fine-grained access control + delegation ("let foo
> control this domain"), and will it be PAM-based too?

It "would be nice", but it's not going to land soon.

> I suppose I'm confused on what the plans are for authentication, delegation and
> auditing in both the local-user and the remote-user cases.

For Xen-API 1.0, authentication is restricted to checking a username/password
pair through the PAM stack, as discussed above. External mechanisms can then
be used to protect the on-wire messages, and restrict access to Xend to a
trusted group. If you prefer, you can disable Xend's authentication
mechanisms, and defer to SSH or similar.

No-one's put any effort into placing an audit trail through Xend, though one
could certainly do that.

Ewan.

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

On Tue, Feb 06, 2007 at 03:58:59PM +0000, Ewan Mellor wrote:

> > The API authorization uses the PAM 'login' stack. If I'm understanding things
> > right, this means that any user/pass pair that matches /etc/passwd etc. will be
> > able to log in. This seems really odd to me - why are matching up "can start a
> > session in xend api" with "has a login account under the name services"? Given
> > this doesn't provide meaningful authentication, what is the session intended
> > for? Shouldn't we be using a new service name along with a pam_xendauth module
> > or similar?
>
> Yes, we almost certainly use a new service name

OK.

> You could write a very small setuid program that allowed access to the local
> socket, or you could set-up sudo to allow similar things.

> We don't use uuidgen -- we randomly generate a 128 bit UUID, without the
> time- or location- based aspect to the UUID that is possible with (some
> versions of) uuidgen.
>
> I think that 128 bits of randomness (using the non-secure RNG) is sufficient
> for a short-lived session token such as this one. You wouldn't generate your
> PGP keys like this, but for short-lived tokens it's fine.

I suppose I don't quite understand what the PAM usage in xend is for then. It
can't provide any additional security (since we must gate users at the point of
access over a secure transport). Obviously you'd like 'username' so that later
auditing features can use it, but surely it's the responsibility of the secure
transport to provide that and make sure it's authorized anyway.

regards
john

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

On Tue, Feb 06, 2007 at 08:29:13PM +0000, John Levon wrote:

> I suppose I don't quite understand what the PAM usage in xend is for then. It
> can't provide any additional security (since we must gate users at the point of
> access over a secure transport). Obviously you'd like 'username' so that later
> auditing features can use it, but surely it's the responsibility of the secure
> transport to provide that and make sure it's authorized anyway.

Your secure transport might not have any per-user authentication. It would
not be unreasonable to use SSL without client certificates, for example.

Ewan.

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