Software

Unix security, maintaining a secure environment on Unix and Unix-like operating systems is dependent on design concepts of these operating systems, but vigilance through user and administrative techniques is important to maintain security also.

Make Money From Home

Design concepts

Permissions

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

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.

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

Issues

Most Unix style 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, passwords are usually stored under the file /etc/passwd. This file also keeps track of the users registered in the system and their main definitions. 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:

xfze:$1$zuW2nX3sslp3qJm9MYDdglEApAc36r/:1000:100:José Carlos D. S. Saraiva:/home/xfze:/bin/bash

Since all users must have read access to this file, in order for the system to check the login password, one security issue was raised: anyone could have read the file and retrieve the password hashes of other users. To solve this problem, the file /etc/shadow was created to store the passwords, with only root having read access. Under password shadowing, the /etc/passwd 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 usually only contains the first two fields:

xfze:$1$zuW2nX3sslp3qJm9MYDdglEApAc36r/:::::

The remaining fields in the /etc/shadow file include:

  1. The minimum number of days between password changes
  2. The maximum number of days until the password must be changed
  3. The number of days of warning given before the password must be changed
  4. The number of days after the password must be changed when the account becomes unusable
  5. 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, sudosh, ssh only, no remote root logins

Software Maintenance

Patching

Operating systems, like all software, may contain bugs in need of fixing or may be enhanced with the addition of new features. Patching the operating system in a secure manner requires that the software come from a trustworth source and not have been altered since it was packaged. Common methods for verifying that operating system patches have not been altered include the use of cryptographic hash, such as an MD5 based checksum, or the use of read-only media.

From a security standpoint, the specific packaging method, such as the RPM Package Manager format originally from Red Hat Linux is not as important as the use of features which ensure the integrity of the patch itself.

Source Distributions

Source distributions include the ability to examine the code for suspicious content. The drawback, absent an accompanying cryptographic hash value, is that the user must be able to perform a security analysis of the code themself.

RPM Packages

Linux distributions which use the RPM Package Manager format for providing base functionality and software updates make use of MD5 and GPG to ensure content integrity. The hash values are packaged with the RPM file and verified when the package is installed.

Debian Packages

Linux distribution which use the Debian .deb package format for providing base functionality and software updates make use of GPG signatures to ensure content integrity. A signature is computed when the package is constructed and verified later when the package is installed.

Other vendors and distributions

Regardless of the vendor or distribution, all software distributions should provide a mechanism for verifying that the software is legitimate and has not been modified since it was originally packaged.