Subject: security/4555: /etc.daily can give misleading advice
To: None <firstname.lastname@example.org>
From: Eric S. Hvozda <email@example.com>
Date: 11/21/1997 08:34:24
>Synopsis: Following advice from /etc/daily about user '+' disables all NIS logins
>Responsible: gnats-admin (GNATS administrator)
>Arrival-Date: Fri Nov 21 05:35:01 1997
>Release: NetBSD 1.3_ALPHA supped 19Nov97
System: NetBSD ra.ack.org 1.3_ALPHA NetBSD 1.3_ALPHA (RA) #0: Thu Nov 20 21:37:02 EST 1997 firstname.lastname@example.org:/usr/src/sys/arch/i386/compile/RA i386
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.
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:
...and the following was added to /etc/ftpusers:
Logout and attempt to log back (or ftp) in as any NIS user. Note
no logins are permitted for you now.
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
This would seem to imply that + has root equivalence and yet
no shell specified. Dangerous (isn't the default shell
/bin/sh)? Perhaps. Would:
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...