This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/11134] getpwnam shows shadow passwords of NIS users


------- Additional Comments From Christoph dot Pleger at cs dot tu-dortmund dot de  2010-04-07 07:56 -------
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

------- Additional Comments From drepper at redhat dot com  2010-04-07 14:41 -------
I decided to implement this but only as a non-default mode.  It can be selected
by a new variable in /etc/default/nss.  This is as far as I'm willing to go.  As
I explained, the current code has its own justification and is not broken.

Your last patch still contained a bunch of mistakes.  The change I checked in
really has not much to do with it.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=11134

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]