Re: getppid misused as entropy source

[Bruno Rohee <bruno_(_at_)_rohee_(_dot_)_com>]

On Tue, Mar 08, 2005 at 04:50:57PM -0300, Fabio Olive Leite wrote:
> On Tue, Mar 08, 2005 at 03:27:55PM +0100, Bruno Rohee wrote:
> > 
> > I'm afraid that this patch is wrong, the return value from getppid()
> > was constrained in the 2-65535 range and the call to arc4random()
> > isn't. And I think it's bad in that context. I'll look at it again tonight.
> 
> I admit I do not know the protocol, so I don't know all of the
> implications of that change. It's just that the code looked so weird
> "I need an auth_port (whatever it is), let's get the ttyslot(). Oh
> wait, it was zero? Then get the parent pid.".
> 
> BTW, the range of getppid() is 1-32766.

Well, I looked at the RADIUS RFC and your proposal is at least
partially wrong. 

The field in the RADIUS request that you proposed to randomize
is defined as NAS-Port in RFC 2865 and is used to specify which
port of the device the login requester connect to. One can then
limit login in his RADIUS configuration to something like people
connecting only via the modem plugged on the second serial port
(which number is returned by the ttyslot() code). Your proposed
change just break that feature for no good reasons.

Then in the login is not via a tty we have to supply something else,
then maybe we could replace the getppid() with a call to arc4random()
since this is not very meaningful, but at least constraing the value to
the same range at getppid() to be sure we don't startle radiusd with
completely out of reasonable range values...

But it was not at all a case a getppid() used as a source of entropy
as you thought.

-- 
If God is dead, who will save the Queen?