The original question was:
>
> Why does putting an asterisk ("*") in the password field of
> the NIS magic token ("+:*:0:0:::") disable the passwd map?
>
> Let me clarify. I have an NIS client with a very bare /etc/passwd file.
> The last line of the file is "+::0:0:::", telling the system to append the
> global NIS passwd map. This works fine.
>
> Then one day I read that the above line is a big security risk. Should NIS
> stop running for some reason, the line would act as a UID 0 login for the
> user "+" with no password! Therefore, a "*" should be placed in the
> password field, making the line read "+:*:0:0:::". But when I tried it,
> the NIS passwd map was not appended. Take the "*" out again, no problem.
>
> The same holds for adding a single user NIS entry (i.e., "+user::0:0:::"
> works, "+user:*:0:0:::" doesn't). Ironically, /etc/group does NOT suffer
> from the same problem.
>
> This has been true for ALL releases of SunOS from 4.0.3 to 4.1.3_U1 Rev. B.
> Does anyone know what the problem is? And is the risk of NIS failing a
> formidable threat?
And the answer is:
1. First of all, the "*" in the password field does not disable the passwd
map. It merely replaces that [password] field for all lines in the map.
(Thanks C.R.Ritson@newcastle.ac.uk!)
In other words, all NIS-included users would not be able to login because
their password field contains "*". But the passwd map is still available,
as evidenced by the UID->username translation still working when you do
'ls -lg'.
The confusion arose because the O'Reilly & Associates book I was using
("Managing NFS and NIS", (C) Copyright 1991) said only the last three
fields (gecos, home dir., shell) could be overridden in by a "+" entry
in the local /etc/passwd. The truth is that the password field can also
be overridden!
The moral of this story is to leave the password field blank for "+"
entries unless you REALLY wan't to override it.
2. Secondly, there is no security risk whatsoever by having a "+" entry in
a client's /etc/passwd with a blank password field, at least on NIS-
aware systems such as SunOS.
What this means is that system calls in SunOS (such as getpwent, used
to return a passwd entry) know about NIS, regardless of whether NIS
processes are running on the system or not. The special "+" entries
will NOT be interpreted as real users. (Thanks tom@sees.bangor.ac.uk!)
However, if you are truly paranoid, you can replace the 0 in the UID and
GID with 65534 (nobody's UID/GID). I tested this and it works also. But
this is completely unnecessary since the line will not be interpreted as
a real user anyway. Furthermore, the 0 UID/GID will not override real
users' UIDs/GIDs in the NIS map - NIS always supplies both the UID and
GID. The 0's in the "+" entry are just dummy values - place holders.
Special thanks to the following:
Tom Orban <orban@advtech.uswest.com>
Ted Nolan <ted@ags.ga.erg.sri.com>
Tom Crummey <tom@sees.bangor.ac.uk>
Casper Dik <casper@fwi.uva.nl>
C.R. Ritson <C.R.Ritson@newcastle.ac.uk>
Paulo Licio de Geus <paulo@dcc.unicamp.br>
Here are the original responses:
------------------------------------------------------------------------------
>From: Tom Orban <orban@advtech.uswest.com>
I read about that in some security book a while back and tried it on
a machine running 413 I believe. With NIS not running, I still couldn't
log in with user name of "+". Try it and let me know if you find something
different.
Bottom Line: I think sun did some workaround to prevent that.
-Tom
------------------------------------------------------------------------------
>From: Ted Nolan SRI Ft Gordon <ted@ags.ga.erg.sri.com>
Hello,
I don't have a specific answer to your question, but I just killed ypbind
on my machine then tried to login as '+' (SunOs 4.1.3). It didn't let
me. Are you sure leaving it blank is a security hole? Have you tried it?
Ted Nolan
------------------------------------------------------------------------------
>From: Mr T Crummey (DIJ) <tom@sees.bangor.ac.uk>
Hello Matthew,
The * in the line means replace the passwords in all YP inlcuded fields
with *. This means that people cannot log in as you have found out.
The security hole you refer to is imaginary as the getpwent call will not
interpret this line as a real user even if YP is not running as it is the
same library call no matter what.
Tom.
------------------------------------------------------------------------------
>From: Casper Dik <casper@fwi.uva.nl>
Only on systems not aware of NIS this might be a problem. Using a "*"
is a problem on any NIS aware version of SunOS I've ever used.
Not using a "*" is not a security problem on SunOS (any release).
It is on some otehr vendors systems (probably Ultrix :-)
Casper
------------------------------------------------------------------------------
>From: "C.R. Ritson" <C.R.Ritson@newcastle.ac.uk>
You can override password entries too. Adding the * forces all
passwords to be interpreted as *, I guess, although I have previously
only seen this behaviour for single-user entries, I suspect this
must be happening to the global include token.
This is only a potentail security risk if your machine fails to
bind to a server, or comes un-bound. I don't know how rare that
is. What I ended up doing was to change the UID/GID on the template
line to something innocuous - eg the ones already in use for nobody,
or else 65535.
Chris Ritson.
------------------------------------------------------------------------------
>From: paulo@dcc.unicamp.br (Paulo Licio de Geus)
As far as I know, any field that is filled in an NIS entry (a "+"
line) takes precedence over the corresponding field in the NIS map.
In fact, I've told the system that all accounts not matched previously
(the line starting with "+:") should have a single password, whose
encryption results int he string "*", which I believe is not possible
via crypt(1). So, all you NIS accounts have in fact blocked from any
login. Nothing strange about that...
------------------------------------------------------------------------------
===========================================================================
Matthew R. Hofener, System/Network Administrator (matthew.hofener@camp.org)
NIST Great Lakes Manufacturing Technology Center (GLMTC)
A Division of Cleveland Advanced Manufacturing Program (CAMP)
===========================================================================
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:16 CDT