User and Group Security

The concept of the user is central to Solaris ”all processes and files on a Solaris system are owned by a particular user and are assigned to a specific user group. No data or activities on the system may exist without first establishing a valid user or group. Managing users and groups as a Solaris administrator can be a challenging activity ”you will be responsible for assigning all the privileges granted or denied to a user or group of users, and many of these permissions carry great risk. For example, a user with an inappropriate privilege level may execute inappropriate commands as the superuser, causing damage to your system.

You can determine which user you are currently logged in as from a terminal session by using the id command:

 $ id uid=1001(natashia) gid=10(dialup)

The output shows that the currently logged-in user is natashia, with UID=1001. In addition, the current group of natashia is a dial-up group with GID=10. It is possible for the user and group credentials to change during a single terminal session. For example, if the su facility is used effectively to become the superuser, the UID and GID associated with the current terminal session will also change:

 $ su root Password: # id uid=0(root) gid=1(other)

Here, the root user (UID=0) belonging to the group other (GID=1) has spawned a new shell with full superuser privileges.

You can obtain a list of all groups that a user belongs to by using the groups command. For example, to view all the groups that the root user belongs to, we use the following command:

 # groups root other root bin sys adm uucp mail tty lp nuucp daemon

Protecting the Superuser Account

We ve just examined how to use the su facility to invoke superuser privileges from an unprivileged account. The user with UID=0 (typically the root user) has unlimited powers to act on a Solaris system. The root user can perform the following potentially dangerous functions:

Add, delete, or modify all other user accounts
Read and write all files, and create new ones
Add or delete devices to the system
Install new system software
Read everyone s e-mail
Snoop network traffic for usernames and passwords of other systems on the local area network (LAN)
Modify all system logs to remove all traces of superuser access
Pretend to be an unprivileged user and access their accounts on other systems where login access is authenticated against a username

These powers combine to make the root account sound rather sinister; however, many of these activities are legitimate and necessary system administration routines that are undertaken daily. For example, network traffic can be snooped to determine where network outages are occurring, and copying user files to backup tapes every night is generally in everyone s best interest. However, if an intruder gains root access, he or she is free to roam the system, deleting or stealing data, removing or adding user accounts, or installing Trojan horses that can transparently modify the way that your system operates.

One way to protect against an authorized user gaining root access is to use a hard-to-guess root password. This makes it difficult for a cracker to use a password- cracking program to guess your password successfully. The optimal password is a completely random string of alphanumeric and punctuation characters .

Tip

The root password should never be written down unless it is locked in the company safe, nor should it be told to anyone who doesn t need to know it. The root password must usually be entered twice ”just in case you should happen to make a typographic error, as the characters that you type are masked on the screen.

The root user should never be able to log in using telnet: instead, the su facility should be used by individual users to gain root privileges where necessary. This protects the root account since at least one other password is required to log in, unless the root user has access to the console. In addition, the su command should be owned by a sysadmin group (or similar) so that only those users who need access to the root account should be able to obtain it. Once su has been used to gain root access, the root user can use su to spawn a shell with the effective ID of any other user on the system. This is a security weakness, because the root user could pretend to be another user and perform actions or modify data traceable to the effective user and not root.

The / etc/passwd and /etc/shadow Password Files

Solaris has reduced the chances of a rogue user obtaining the password file in the first place by implementing a shadow password facility. This creates a file called /etc/shadow that is similar to the password file ( /etc/passwd ) but is readable only by root and contains the encrypted password fields for each UID. Thus, if a rogue user cannot obtain the encrypted password entries, it is impossible to use them as the basis for a crack attack.

A shadow password file corresponding to the password file shown previously looks like this:

 # cat /etc/shadow root:YTS88sd7fSS:10528:::::: daemon:NP:6445:::::: bin:NP:6445:::::: sys:NP:6445:::::: adm:NP:6445:::::: lp:NP:6445:::::: uucp:NP:6445:::::: nuucp:NP:6445:::::: listen:*LK*::::::: nobody:NP:6445:::::: noaccess:NP:6445:::::: nobody4:NP:6445:::::: security:*LK*::::::: natashia:hY72er3Ascc:::::::

If a system is correctly installed, the /etc/passwd file should be readable by all users, but it should contain no passwords. Conversely, the /etc/shadow file should be readable only by root and should contain the encrypted password strings traditionally stored in /etc/passwd .