5.4.1 NIS+ and the passwd Table

NIS+ Passwd Tbl

Figure 5-1

5.4.1 NIS+ and the Password Table

HP-UX 11i 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 environment.

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 command:

niscat -h passwd.org_dir

smokey:v4sL5vFQjQWQ2:4009:20:,,,:/home/smokey:/usr/bin/sh: bvaught:D5QPwERnJ5fWE:4006:20:,,,:/home/bvaught:/usr/bin/sh: jsmith:O5iekxm8SmhAQ:4010:20:,,,:/home/jsmith:/usr/bin/sh: jrice:e58pcdIVHD8uM:4004:20:,,,:/home/jrice:/usr/bin/sh: brankin:.6G.c23hKwGDY:4005:20:,,,:/home/brankin:/usr/bin/sh: alinker:P7XbAX7UOxGK6:4011:20:,,,:/home/alinker:/usr/bin/sh: user01:E9npNCrXrC7iw:5001:102:,,,:/home/user01:/usr/bin/sh:

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 show why.

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
[0] Name : name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : r---r---r---r---
[1] Name : passwd Attributes : (TEXTUAL DATA) Access Rights : ----rm--r---r---

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:

jrice:*NP*:4004:20:,,,:/home/jrice:/usr/bin/sh:*NP* brankin:*NP*:4005:20:,,,:/home/brankin:/usr/bin/sh:*NP* alinker:*NP*:4011:20:,,,:/home/alinker:/usr/bin/sh:*NP* bobr:*NP*:4003:20:,,,:/home/bobr:/usr/bin/sh:*NP* bobby:*NP*:4100:20:,,,:/home/bobby:/usr/bin/sh:*NP* bshaver:*NP*:4013:20:,,,:/home/bshaver:/usr/bin/sh:*NP* bwalton:*NP*:4012:20:,,,:/home/bwalton:/usr/bin/sh:*NP* vking:*NP*:4002:20:,,,:/home/vking:/usr/bin/sh:*NP* user01:aos1wLnAUDG62:5001:102:,,,:/home/user01:/usr/bin/sh:11637::::::0

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.