Unix security refers to the means of securing a Unix or Unix-like operating system. A secure environment is achieved not only by the design concepts of these operating systems, but also through vigilant user and administrative practices.

Design concepts

Permissions

A core security feature in these systems is the file system permissions. All files in a typical Unix filesystem have permissions set enabling different access to a file.

Unix security

Permissions on a file are commonly set using the chmod command and seen through the ls command. For example: -r-xr-xr-x 1 root wheel 745720 Sep 8 2002 /bin/sh

Unix security

Unix permissions permit different users access to a file. Different user groups have different permissions on a file.

Unix security

More advanced Unix filesystems include the Access Control List concept which allows permissions to be granted to multiple users or groups. An Access Control List may be used to grant permission to additional individual users or groups. For example: /pvr [u::rwx,g::r-x,o::r-x/u::rwx,u:sue:rwx,g::r-x,m::rwx,o::r-x]

In this example, which is from the command on the Linux operating system, the user sue is granted write permission to the /pvr directory.

User groups

Users under Unix style operating systems often belong to managed groups with specific access permissions. This enables users to be grouped by the level of access they have to this system. Many Unix implementations add an additional layer of security by requiring that a user be a member of the wheel user privileges group in order to access the su command.

Root access

Most Unix and Unix-like systems have an account or group which enables a user to exact complete control over the system, often known as a root account. If access to this account is gained by an unwanted user, this results in a complete breach of the system. A root account however is necessary for administrative purposes, and for the above security reasons the root account is seldom used for day to day purposes (the sudo program is more commonly used), so usage of the root account can be more closely monitored.

Root access "as it should be" can be visualised by those familiar with the Superman stories using the following analogy:

Using a root account is rather like being Superman; an administrator's regular user is more like Clark Kent. Clark Kent becomes Superman for only as long as necessary, in order to save people. He then reverts to his "disguise". Root access should be used in the same fashion. The Clark Kent disguise doesn't really restrict him though, as he is still able to use his super powers. This is analogous to using the sudo program.

User and administrative techniques

Unix has many tools that can improve security if used properly by users and administrators.

Passwords

Selecting a strong password and guarding it properly are probably the most important things a user can do to improve Unix security. In Unix systems, the essential information about users is stored under the file /etc/passwdThis file keeps track of the users registered in the system and their main definitions. Passwords, or more correctly, the hash of the password, can also be stored in the same place. The entries in /etc/passwd occupy exactly one line each, and have the following form:

nickname:password_hash:UserID:GroupID:Complete_Name:home_dir:shell_bin

An example would be:

Since all users must have read access to the /etc/passwd file to do many common tasks (ls -l /home will use /etc/passwd to map UIDs to login names for example), anyone could also read the password hashes of other users. To solve this problem, the file /etc/shadow was created to store the password hashes, with only root having read access. Under password shadowing, the 2nd field (password hash) is replaced by an 'x' which tells the system to retrieve the corresponding user's password via the /etc/shadow file.

The /etc/shadow file often only contains values for the first two fields:

The remaining fields in the /etc/shadow file include: The minimum number of days between password changes The maximum number of days until the password must be changed The number of days of warning given before the password must be changed The number of days after the password must be changed when the account becomes unusable The date (expressed as the number of days since January 1st, 1970) when the account is expired

These fields may be used to improve Unix security by enforcing a password security policy.

Users and accounts

Administrators should delete old accounts promptly. su, sudo, ssh only, no remote root logins