[ Bottom of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]

Security Guide

System Special User Accounts

AIX provides a default set of system special user accounts that prevents root and system from owning all operating system files and file systems.

Attention: Use caution when removing a system special user account. You can disable a specific account by inserting an asterisk (*) at the beginning of its corresponding line of the /etc/security/passwd file. However, be careful not to disable the root user account. If you remove system special user accounts or disable the root account, the operating system will not function.

The following accounts are predefined in the operating system:

The root user account, UID 0, sometimes called the superuser account, through which you can perform system maintenance tasks and troubleshoot system problems.
The daemon user account exists only to own and execute system server processes and their associated files. ) This account guarantees that such processes execute with the appropriate file access permissions.
The bin user account typically owns the executable files for most user commands. This account's primary purpose is to help distribute the ownership of important system directories and files so everything is not owned solely by the root and sys user accounts.
The sys user owns the default mounting point for the Distributed File Service (DFS) cache, which must exist before you can install or configure DFS on a client. The /usr/sys directory can also store install images.
The adm user account owns two basic system functions:
  1. Diagnostics, the tools for which are stored in the /usr/sbin/perf/diag_tool directory.
  2. Accounting, the tools for which are stored in the following directories:
    • /usr/sbin/acct
    • /usr/lib/acct
    • /var/adm
    • /var/adm/acct/fiscal
    • /var/adm/acct/nite
    • /var/adm/acct/sum
The nobody user account is used by the Network File System (NFS) product to enable remote printing. This account exists so a program can permit temporary root access to root users. For example, before turning on Secure RPC or Secure NFS, check the /etc/public key on the master NIS server to find a user has not been assigned a public key and a secret key. As root user, you can create an entry in the database for each unassigned user by entering:

newkey -u username
Or, you can create an entry in the database for the nobody user account, and then any user can run the chkey program to create their own entries in the database without logging in as root.

Removing Unnecessary Default User Accounts

During installation of the operating system, a number of default user and group IDs are created. Depending on the applications you are running on your system and where your system is located in the network, some of these user and group IDs can become security weaknesses, vulnerable to exploitation. If these users and group IDs are not needed, you can remove them to minimize security risks associated with them.

The following table lists the most common default user IDs that you might be able to remove:

Table 6. Common default user IDs that you might be able to remove.
User ID Description
uucp, nuucp Owner of hidden files used by uucp protocol. The uucp user account is used for the UNIX-to-UNIX Copy Program, which is group of commands, programs, and files, present on most UNIX systems, that allows the user to communicate with another UNIX system over a dedicated line or a telephone line.
lpd Owner of files used by printing subsystem
imnadm IMN search engine (used by Documentation Library Search)
guest Allows access to users who do not have access to accounts

The following table lists common group IDs that might not be needed:

Table 7. Common group IDs that might not be needed.
Group ID Description
uucp Group to which uucpand nuucp users belong
printq Group to which lpd user belongs
imnadm Group to which imnadm user belongs

Analyze your system to determine which IDs are indeed not needed. There might also be additional user and group IDs that you might not need. Before your system goes into production, perform a thorough evaluation of available IDs.

[ Top of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]