File Security Features

This section describes the features that constitute a file's security.

User Classes

For each file, there are three classes of users that specify the levels of security:

• The file or directory owner--usually the user who created the file. The owner of a file can decide who has the right to read it, to write to it (make changes to it), or, if it is a command, to execute it.

• Members of a group.

• All others who are not the file or group owner.

Only the owner of the file or root can assign or modify file permissions.

File Permissions

The table below lists and describes the permissions you can give to each user class for a file.

These file permissions apply to special files such as devices, sockets, and named pipes (FIFOs), as they do to regular files.

For a symbolic link, the permissions that apply are those of the file the link points to.

Directory Permissions

The table below lists and describes the permissions you can give to each user class for a directory.

You can protect the files in a directory (and in its subdirectories) by disallowing access to that directory. Note, however, that superuser has access to all files and directories on the system.

Special File Permissions (setuid, setgid and Sticky Bit)

Three special types of permissions are available for executable files and public directories. When these permissions are set, any user who runs that executable file assumes the user ID of the owner (or group) of the executable file.

You must be extremely careful when setting special permissions, because special permissions constitute a security risk. For example, a user can gain superuser permission by executing a program that sets the user ID to root. Also, all users can set special permissions for files they own, which constitutes another security concern.

You should monitor your system for any unauthorized use of the setuid and setgid permissions to gain superuser privileges. See "How to Find Files With setuid Permissions" to search for the file systems and print out a list of all programs using these permissions. A suspicious listing would be one that grants ownership of such a program to a user rather than to root or bin.

setuid Permission

When set-user identification (setuid) permission is set on an executable file, a process that runs this file is granted access based on the owner of the file (usually root), rather than the user who is running the executable file. This allows a user to access files and directories that are normally only available to the owner. For example, the setuid permission on the passwd command makes it possible for a user to change passwords, assuming the permissions of the root ID:

-r-sr-sr-x   3 root     sys       104580 Sep 16 12:02 /usr/bin/passwd

This presents a security risk, because some determined users can find a way to maintain the permissions granted to them by the setuid process even after the process has finished executing.

Using setuid permissions with the reserved UIDs (0-99) from a program might not set the effective UID correctly. Use a shell script instead or avoid using the reserved UIDs with setuid permissions.

setgid Permission

The set-group identification (setgid) permission is similar to setuid, except that the process's effective group ID (GID) is changed to the group owner of the file, and a user is granted access based on permissions granted to that group. The /usr/bin/mail program has setgid permissions:

-r-x--s--x   1 root     mail       63628 Sep 16 12:01 /usr/bin/mail

When setgid permission is applied to a directory, files created in this directory belong to the group to which the directory belongs, not the group to which the creating process belongs. Any user who has write and execute permissions in the directory can create a file there--however, the file belongs to the group owning the directory, not to the user's group ownership.

You should monitor your system for any unauthorized use of the setuid and setgid permissions to gain superuser privileges. See "How to Find Files With setuid Permissions" to search for the file systems and print out a list of all programs using these permissions. A suspicious listing would be one that grants ownership of such a program to a user rather than to root or bin.

Sticky Bit

The sticky bit is a permission bit that protects the files within a directory. If the directory has the sticky bit set, a file can be deleted only by the owner of the file, the owner of the directory, or by root. This prevents a user from deleting other users' files from public directories such as /tmp:

drwxrwxrwt 7  root  sys   400 Sep  3 13:37 tmp

Be sure to set the sticky bit manually when you set up a public directory on a TMPFS file system.

Default umask

When you create a file or directory, it has a default set of permissions. These default permissions are determined by the value of umask(1) in the system file /etc/profile, or in your .cshrc or .login file. By default, the system sets the permissions on a text file to 666, granting read and write permission to user, group, and others, and to 777 on a directory or executable file.

The value assigned by umask is subtracted from the default. This has the effect of denying permissions in the same way that chmod grants them. For example, while the command chmod 022 grants write permission to group and others, umask 022 denies write permission for group and others.

The table below shows some typical umask settings, and the effect on an executable file.