>Number:         4555
>Category:       security
>Synopsis:       Following advice from /etc/daily about user '+' disables all NIS logins
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Nov 21 05:35:01 1997
>Last-Modified:
>Originator:     
>Organization:
	
>Release:        NetBSD 1.3_ALPHA supped 19Nov97
>Environment:
	
System: NetBSD ra.ack.org 1.3_ALPHA NetBSD 1.3_ALPHA (RA) #0: Thu Nov 20 21:37:02 EST 1997 hvozda@ra.ack.org:/usr/src/sys/arch/i386/compile/RA i386


>Description:
	After a host is made to be an NIS client, the next run of 
	/etc/daily will complain as below:

          Checking the /etc/master.passwd file:
          Login + has non-alphanumeric characters.
          Login + is off but still has a valid shell ()
          Login + has a negative user id.
          Login + has a negative group id.
          
          Checking the /etc/group file:
          Group + has non-alphanumeric characters.
          
          Checking the /etc/ftpusers configuration:
          	+ is not denied

	After following the /etc/daily's advice, discover on the next
	login attempt of any NIS user that logins are disabled as
	well as ftp access.

	Opps :-)

>How-To-Repeat:
	Install NetBSD 1.3_ALPHA and enable it as an NIS client.  Observe
	/etc/daily's mail at root on the next cycle and follow its
	advice; add the following as changed in /etc/passwd via vipw:

	+:*:::::::/tmp:/sbin/nologin

	...and the following was added to /etc/ftpusers:

	+	deny

	Logout and attempt to log back (or ftp) in as any NIS user.  Note
	no logins are permitted for you now.
>Fix:
	Is /etc/daily's advice actually correct considering that '+' is
	the known cookie for NIS?  There is the issue of if someone
	is actually unknowning enough to place a '+' in /etc/hosts.equiv
	and now no passwd authentication is done and somone may be able to 
	get a shell (untested at this time) as user '+'.  However, there
	is more than enough documentation available from other sources
	out there on this issue but I digress.

	It would seem non-intuitive that '+' would affect users
	authentication in this way.  Further I note that the following
	entry is in /etc/passwd itself for the cookie (before following
	/etc/daily's advice):

	+:*:0:0:::

	This would seem to imply that + has root equivalence and yet
	no shell specified.  Dangerous (isn't the default shell
	/bin/sh)?  Perhaps.  Would:

	+:*:0:0:::/sbin/nologin

	be more appropriate?  Unknown.

	Then again /etc/passwd is the public copy of the database,
	perhaps the hashed version is not like the former.

	At anyrate, perhaps /etc/daily should be changed to not do
	its tests for '+' if the proper protections are in place
	in system calls or the respective subsystems.

	Currently at the worst, logins get disabled.  However
	this is easily fixed.  It's just annoying.

	We should probably discuss this at length in tech-security...
>Audit-Trail:
>Unformatted: