Comment 22 for bug 499425

Subject: Re: getpwnam shows shadow passwords of NIS users

Hello,

> The server can regulate which process can read the passwd.adjunct
> database using the source port number. A value < 1024 would indicate
> privileges. If an attacker can illegally bind a socket to a low port
> security is already compromised.

Normal permissions should prevent an attacker from illegally binding a
socket to a port < 1024. Of course there can be a security hole that
gives root privileges. But a security hole of that kind gives access to
everything, in spite of that no sensible administrator gives
permissions 777 to all files. So, we must find a solution for the
normal case which says that no ordinary user can use a port < 1024,
not a solution for a case where another security hole is already
present.

Of course a user can connect his own notebook to the network, be root
on it, which allows to use a port < 1024, and read the encrypted
passwords. But that problem can be solved by other means, for example
by IPSec authentication.

> That's how it is meant to be used. In this model processes with
> privileges can get to the information. Especially because I don't
> think imitating the shadow file using the passwd.adjunct content is
> going to work.

Where do you see a problem? I've been using this for some time now and
the only problem I found was the overwriting of the password field,
which I solved by the modified patch.

> You say there are two fields missing in passwd.adjunct. In theory
> perhaps true but I have not found anywhere any indication that
> usually the file contains any information except the first two
> fields.

Right, that is why I put empty strings into these fields. These
field are defined in libc6, what will getspnam do if they are not
present?

> There is no way in Sun's implementation to enable behavior
> like this? There is no setting in Sun's ypserv to restrict access
> based on ports? I cannot change it without a good reason.

The access IS restricted on ports. But that does not help when,
on the Linux client side, nscd is in use.

> The current libc implementation works perfectly if you use the model I
> described. You get a full passwd file for privileged users and a
> version without the password for non-privileged users.

Unfortunately, that is not true. The current implementation allows
EVERY user to use the getpwnam library call to see the encrypted
password of any NIS user.

> This is a
> sensible model and your patch would cause it to stop working.

No, my patch MAKES it working.

Regards
  Christoph