5.4.1 NIS+ and the Password Table
Security, by Chris Wong, Prentice Hall PTR; ISBN: 0130330620
As mentioned in
the previous section, if the NIS+ environment was previously a NIS
environment, it is possible that everyone can read the hashed passwords.
This includes those who are not authenticated. However, by default (November
2001), when you implement NIS+, the hashed password remains readable by any
authenticated user, even if you aren’t coming from a previous NIS
Why is this? Before implementing NIS+ it is important to have a basic
understanding of the permissions associated with tables. In the previous
section we covered the four permission groups: owner, group, world, and
nobody. The biggest difference between NIS+ and UNIX is that in NIS+ the
order of the groups as they are associated with the permissions are: nobody,
owner, group, and world. This takes a little bit for the UNIX administrator
to get used to. We are used to looking at the last set of permissions to see
the permissions available to the largest group of users (world or other).
However, in NIS+, this group is the first group: nobody. Now, nobody doesn’t
mean “no one”. It means that this is the group used when a user has no
credentials, when they are not authenticated. It gets even more complicated.
In UNIX, “read, write, and execute” are assigned. In NIS+ there are four
settings: read, write, modify, and destroy.
Let’s take a journey through NIS+ permissions. We will start by reading the
contents of the password table. This can be done by using the niscat
niscat -h passwd.org_dir
The above command was executed by a regular (non-root) user. As you can see,
the users hashed password is readable. The immediate thought when converting
to NIS+ is that since the passwords are now in a table, that they would be
protected. This is an incorrect assumption. The “niscat –o” command will
Object Name : passwd
Owner : ctg500g.cerius.com.
Group : admin.cerius.com.
Domain : org_dir.cerius.com.
Access Rights : ----rmcdrmcdr---
Time to Live : 12:0:0
Object Type : TABLE
Table Type : passwd_tbl
 Name : name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE)
Access Rights : r---r---r---r---
 Name : passwd
Attributes : (TEXTUAL DATA) Access Rights :
From looking at this information, we can see that
there are separate permissions for each field. The passwd field, which
contains the hashed password, has the following permissions:
None for those with no credentials
Read and modify for owner
Read for group
Read for those with credentials that aren’t the owner or group
Any good UNIX administrator will look at this and fix the problem of the
passwords being readable by removing the read permission for other. To
remove the read access to the passwd column for “world” the nistbladm (NIS
Table Admin) command can be used:
nistbladm –u passwd=w-r passwd.org_dir
This command removes (-) the read (r) access from the world (w) or other
group from the passwd column (passwd=) in the password table (passwd.org_dir).
After changing the permissions, the regular user executes the command to
view the contents of the file. The exact same information is displayed to
the user, they can still read the hashed password. Urghhh!
Take a look at Figure 5-1. This demonstrates the way that NIS+ tables work.
If a user’s credentials pass at one layer, they have access to the data
record. It doesn’t matter what the permissions are at the other layers. If
you go back and look at the permissions on the password table you will see
they are set to:
None for those with no credentials
Read, modify, create, and destroy for the owner
Read, modify, create, and destroy for the group
Read for anyone with a credential
So, this is very similar to the regular /etc/passwd file. Everyone can read
the /etc/passwd file. In this case, everyone (with a credential that is) can
read the password table because it is set to enable read access to the
world. The nischmod command is used to change the permissions on a table:
nischmod n=,og=rmcd,w= passwd.org_dir
Once this change has been made, the regular user (user01) only sees
their own hashed password when running the niscat command:
All the other entries now display “*NP*” instead. The NP stands for no
permission, as in the user has no permission to read the entry in this
column. The other important note to make is that both steps are required to
eliminate users from being able to read other users entries in the password
table. If only the table permissions were changed, access would still be
granted at the column level.