Unix security

From Free net encyclopedia

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.

Template:Wikibooks

1 Design concepts
2 User and administrative techniques
3 General
4 Advanced
5 Service details

[edit]

Design concepts

[edit]

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.

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 permissions permit different users access to a file. Different user groups have different permissions on 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. 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 chacl command on the Linux operating system, the user sue is granted write permission to the /pvr directory.

[edit]

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

[edit]

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.

[edit]

User and administrative techniques

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

[edit]

Passwords

Selecting a strong password and guarding it properly is 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. Actually this file stores more rather than just passwds, it keeps track of the users registered in the system and their main definitions. The entries in /etc/passwd are like this:

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

But as all users must have access to this file in order for the system to compare the password given at the login prompt with the one stored in the file, one security issue was raised: anyone could have access to the file and retrieve other users' password hash. To solve this problem the protected file /etc/shadow was created to store the passwords, this way in 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 shadow file. See: password shadowing

The shadow file usually only contains the first two fields:

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

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 and 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.

[edit]

Users and accounts

Administrators should delete old accounts promptly.

su, sudo, wheel on bsd, /etc/securetty, ssh only, no root logins

[edit]

Patching

source
rpm based
deb based
freebsd ports and packages
meta - apt, rhn, red carpet

add gentoo, slack, net + openbsd
solaris + propriety (sco?)

[edit]

Services

Only run the services that are needed remove the rest (even better do this at install - only choose necessary packages).

Identify what services are running
netstat -na
lsof
nmap

on *bsd sockstat -4

inetd xinetd

turning off unnecessary services

using chkconfig on Red Hat Linux
using /etc/rc.conf and /usr/local/etc/rc.d on FreeBSD (mention /etc/rc.local)

This approach is usually called proactive security. There are some operating systems secure by default. Amongst others, the free BSD flavours (FreeBSD, NetBSD, and OpenBSD) are proactively secure. For example, the output of netstat on a NetBSD 3.0 workstation clearly outlines this technique:

$ netstat -a
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        State
tcp        0      0  localhost.smtp         *.*                    LISTEN
tcp        0      0  *.ssh                  *.*                    LISTEN
Active Internet6 connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp6       0      0  localhost.smtp         *.*                    LISTEN
tcp6       0      0  *.ssh                  *.*                    LISTEN
Active UNIX domain sockets
Address  Type   Recv-Q Send-Q    Inode     Conn     Refs  Nextref Addr
c0d10d80 dgram       0      0        0 c0cd8680        0 c0cb7000 -> /var/run/log
c0cb7000 dgram       0      0        0 c0cd8680        0        0 -> /var/run/log
c0cd8680 dgram       0      0 cb9639e8        0 c0d10d80        0 /var/run/log

In fact,

$ sockstat -4
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
root     sendmail   569    4 tcp    localhost.smtp        *.*
root     sshd       593    4 tcp    *.ssh                 *.*

shows that on this machine only the secure shell service is listening to the public network interface of the computer. sendmail is listening to the loopback interface only.

[edit]

File system security

File system security within UNIX and UNIX-like systems is based on 9 permission bits, set user and group ID bits, and the sticky bit, for a total of 12 bits. These permissions apply almost equally to all filesystem objects such as files, directories and devices.

The 9 permission bits are divided into three groups of three bits each. The first group describes the permissions of the file owner, the second group describes the permissions of a group associated with the file owner or the directory containing the file, and the third group describes the permissions associated with any process which does not have the same user ID as the file. Each group of three bits contains a bit indicating the read, write or execute access is granted. In the case of directories, execute access is interpreted as the permission to perform a filename lookup within the directory.

The set user ID and set group ID bits, commonly abbreviated set-UID and set-GID respectively, are used to change the identity of the process which executes a file having either or both of those bits set. A file having the set-UID permission bit set will cause a process which executes that file to temporarily switch the effective user ID to that of the file owner. A file having the set-GID permission bit set will cause a process which executes that file to temporarily switch the effective group ID to that of the file group. A process may then alternate between the effective user or group ID which it inherited from the file and the real user or group ID which it inherited when the user logged on to the system. This provides a mechanism by which a process may limit the access rights it possesses to those code regions which require those access rights. This is a form of a security technique known as privilege bracketing and improves program security by limiting the unintended or undesirable actions of a processes. A directory having the set-GID permission bit set will cause a newly created file to have an initial file group value equal to the file group of the directory. This provides a mechanism whereby a subsystem, such as the system's mail subsystem, can create files which have a common file group value so that set-GID processes within that subsystem are then able to read or write the file.

The sticky bit, formally known as the save text on swap bit, derives its name from its original purpose. Originally the sticky bit caused a process's initial memory image to be stored as a contiguous image on the disk drive which was used to store real memory pages when they were not in use. This improved the performance of commonly executed commands by making the initial memory image readily available. Modern UNIX systems no longer perform that function when the bit is set, but the name has been preserved none the less. In the case of files, the sticky-bit may be used by the system to indicate the style of file locking to be performed. In the case of directories, the sticky bit prevents any process, other than one which has super-user privileges or one having an effective user ID of the file owner, from deleting a file within that directory. The sticky bit is most commonly used on publically writable directories, such as the various temporary working space directories on the system.

[edit]