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