
sun.com \| docs.sun.com	How To Buy \| My Sun \| Worldwide Sites

Previous Contents Index Next Next

Chapter 4

Securing Files (Tasks)

This chapter describes the procedures for securing files in the Solaris environment.

The following is a list of the step-by-step instructions in this chapter.

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:

user - The file or directory owner, which is 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.
group - Members of a group.
others - All other users who are not the file owner or group owner.

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

File Permissions

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

Table 4-1 File Permissions

Symbol	Permission	Description
`r`	Read	Designated users can open and read the contents of a file.
`w`	Write	Designated users can write to the file (modify its contents), add to it, or delete it.
`x`	Execute	Designated users can execute the file (if it is a program or shell script), or run the program with one of the `exec(2)` system calls.
`-`	Denied	Designated users cannot read, write, or execute the 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 the permissions of the file that the link points to.

Directory Permissions

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

Table 4-2 Directory Permissions

Symbol	Permission	Description
`r`	Read	Designated users can list files in the directory.
`w`	Write	Designated users can add or remove files or links in the directory.
`x`	Execute	Designated users can open or execute files in the directory. They also can make the directory and the directories beneath it current.

You can protect the files in a directory (and in its subdirectories) by disallowing access to that directory by setting restrictive file permissions. 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 you set special permissions, because special permissions constitute a security risk. For example, a user can gain superuser privileges by executing a program that sets the user ID (UID) 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. To search for and list all of the files that use these permissions, see How to Find Files With setuid Permissions. A suspicious listing 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 special permission 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 special permission presents a security risk, because some determined users can find a way to maintain the permissions that are granted to them by the setuid process even after the process has finished executing.

Note - The use of setuid permissions with the reserved UIDs (0-100) from a program might not set the effective UID correctly. Use a shell script instead or avoid using the reserved UIDs with setuid permissions.