Re: gdm: shadow unfriendly

[Dave Boynton <dboynton worldnet att net>]

Alan Cox wrote:
> 
> > That was the problem, the "nobody" frontend can't be doing the password
> > checking.  Not only would it be unable to check the shadow passwords,
> > but it would probably be considered a major security hole for gdm, a
> > root process, to depend on a non-root process for password
> > authentication. To obtain the passwords, maybe, but I'm still a little
> > concerned about he security implications of that.
> 
> The alternative is root processes running numerous thousands of lines of
> unaudited code subject to a lot of external control in the matters of
> things like resources

I agree completely, but for a "perimeter" app like gdm, we really should
be doing a complete audit anyway. That's why apps like "login" and "xdm"
are so plain looking.  I don't think auditing gtk+ or imlib is likely at
this point, so I agree that it's best to try to contain the damage in a
non-root process.  That doesn't entirely remove the risk, though. 

I, for one, wouldn't run this at all on a machine with a 24x7 connection
to the internet.

> > What if a new exploit is discovered that allows a remote user to obtain
> > "nobody" access to your machine, via Apache, or Sendmail?  Could they
> > then get a process in memory that attacks the gdmgreeter, also running
> > as nobody, to sniff login/passwords? Any process that even handles
> > passwords, must be paranoid.
> 
> Give it its own uid then

For gdmgreeter? Absolutely, much better than using nobody. However, my
point about gdmgreeter not being able to do the actual password
verification still stands. It's just not possible with shadow passwords,
in the normal setup. PAM doesn't help in this case. 

I suppose it would possible to create a new group that contained
gdmgreeter's uid, and make shadow readable by that group, but that would
probably offend the security minded, without some discussion on the
appropriate lists. 

Dave