[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pam_unix_auth cleanup: NIS+ issues

[If your mailer tells you my name is `explode', don't believe it.
 It's just the mailing list software that's forcing me... --okir]

On Thu, 10 Jun 1999 15:49:52 +0200, Thorsten Kukuk wrote:
> > To me, this appears to be an implementation issue in the RPC library,
> > where the auth_des client code picks the netname based on the 
> > current process' effective uid. The problem can be avoided if
> > the authdes client is given a function by which PAM can tell it what
> > netname to use.
> Who should be allowed to tell authdes which netname to use ? If you
> are not carefull with this, everybody could use the key of another
> person who is logged in or doesn't run keylogout.

You misunderstand me. The only reason why RPC currently consults the
effective uid is because it wants to obtain a conversation key from
keyserv. I feel this is bad, and absolutely not necessary, in an
authentication context.

As the authentication process, we shouldn't rely on the keyserv cache
to contain a valid secret key for the user, and we shouldn't overwrite
any secret keys stored by keyserv because we haven't authenticated the
user yet.

What I propose is:

 -	We know the user's uid, so we have the netname.
 -	We have the user's password, so we can decrypt the secret key.
 -	We have the NIS+ server's public key.
 -	We compute the common key
 -	We generate a random conversation key, and encrypt it with
	the conversation key.

The netname and conversation key is all the auth_des code needs to know.

My point is that the above approach does NOT require us to muck around
with keyserv's cache /before we have authenticated the user/. And it
avoids the seteuid business. You don't have to seteuid to user
kukuk in order to transmit a UDP packet that has kukuk's credentials
in it.

How do we pass on the above information to the RPC layer? It's a bit
of overkill to put aditional code into librpc just for this
purpose. Alternatively, we can use a copy of authdes_clnt.c, and replace
the keyserv part with our cooked information. This is linked into
the PAM module. Instead of the seteuid/getspnam calls in PAM, we do

	AUTH	*foo;
	CLNT	*bar;

	foo = authdes_cooked_create(nisplus_serv, window, 0,
				netname, &conv_key);
	bar = clntudp_create(...);
	bar->cl_auth = foo;

	/* Call NIS+ and get the passwd */


> I think it is much more secure to allow only a process with the
> uid of the user/netname to set and use a secret key then to
> allow it everybody.

You're thinking keyserv. I agree that joe should not be allowed to 
overwrite jane's key in keyserv's cache.

But other than that, anybody can use any netname/key combination he wants,
because everybody is able to do the maths and cobbling together of the
relevant UDP packet. I just need your secret key and uid, and can
send a perfectly fine AUTH_DES packet to your NIS+ server.

Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []