Dutch | French | Spanish | Portuguese | Italian | German | Norwegian | Japanese | Chinese | Korean | Russian | Arabic

This article reviews fundamental filesystem and privilege concepts.

When it comes to input and output, UNIX treats everything as a file. In fact, the term file has multiple meanings in UNIX—it can be a

· Regular file. A sequence of data bytes collectively regarded by the operating system as a file.

· Directory file. A list of filenames and pointers to file meta information (that's a fancy way for saying "information about a file"). If you have read access to a directory, it means you can read the contents of the directory—in other words, get a directory listing (a la ls(1)). However, only the UNIX kernel has the capability to modify the contents of this file (for example, insert a new entry).

· Symbolic link. Contains the name of another file. When a symbolic link is accessed, the kernel recognizes the file as such by examining its file-type. It then reads the file contents. The kernel opens the file with the name stored in the symbolic link. System administrators frequently use symbolic links to relocate data to another filesystem while maintaining the path of the parent directory. Attackers, on the other hand, use symbolic links for more nefarious purposes, as we'll cover later.

· Character special. Represents a byte-oriented device. It is the UNIX interface to devices that operate on a byte-by-byte basis, like a terminal device.

· Block special. Functions like a character special file, but for block-oriented devices such as disk drives.

· Socket. Allows one process to communicate with another process—whether on the local system (via Inter Process Communication) or a remote machine. Programs such as Telnet, rlogin, and FTP all use sockets.

· Named pipe. Supports local Inter Process Communication (IPC). Because of the type of queuing used it is sometimes referred to as a FIFO (First In First Out).

Each of these objects is stored in the filesystem. Protecting the filesystem from abuse is critical to the ongoing integrity of your operating system, application programs, and data.

File Attributes

The UNIX filesystem supports a standard set of file attributes or properties. These attributes are stored in a data structure called the inode (index node)—every file has an inode. On Solaris, the inode data structure for the traditional UNIX FileSystem (UFS) is defined in / usr / include / sys / fs / ufs_inode.h.

From a security perspective, the most important attributes include

· The owner id. The numeric user id that owns the file.

· The group id. The numeric group id that owns the file.

· Permissions. Combined with the owner id and group id, these determine the access controls on the file.

· Size. Measured in bytes.

· Time of last access. The time the file was last accessed, in seconds since 1970.

· Time of last modification. The time the file was last modified, in seconds since 1970.

· Time of last inode change. The time the file was created, in seconds since 1970.

· Number of hard links. The number of files that "point" at this file.

The permissions attribute defines the access rights of the file owner, the group owner, and all other users on the system. The root user and file owner can control access to a file by setting permissions on the file and on the parent directories.

In the standard implementation of UNIX, the root user is not subject to permission checking—root can read, write, or execute any file. Note that, in UNIX, write access is equivalent to delete—by definition, if you can write to the file, you can erase the contents of the file.

Readers unfamiliar with filesystem permissions are encouraged to read the chmod man page. For further reading, I highly recommend Advanced Programming in the UNIX Environment, Addison-Wesley, 1992, ISBN 0-201-56317-7.

Permissions in Practice

To access a file by name, a user must have execute privilege in every directory contained in the file path, as well as appropriate access to the file itself. In the case of files in the current directory, a user needs execute privilege for the current directory.

To be able to create a file in a directory, a user must have execute permission on every directory in the path, as well as write permission in the target directory.

When it comes to deleting a file, it isn't actually necessary to be the file owner or have write permission on the file. By having write and execute permissions on the parent directory, you can delete files. This can be a "gotcha" if you're not careful.

In order to understand how the various permissions are checked when a user attempts to open a file, you need to understand how process privileges work.

Put simply, when you execute a program, a process is created. Associated with a process are at least six IDs:

· Real User ID. The numeric user id of your login account

· Real Group ID. The numeric group ID of your primary group (the group defined in your / etc / passwd entry)

· Effective User ID. The numeric user id used during file access permission checks

· Effective Group ID. The numeric group ID used during file access permission checks

· Saved Set User ID. A copy of the numeric user id saved by the exec function when you execute a program

· Saved Set Group ID. A copy of the numeric group ID saved by the exec function when you execute a program

In addition, if you are a member of more than one UNIX group, a corresponding number of supplementary group IDs will be set.

At first glance this might seem overcomplicated. To appreciate why so many IDs are required, we have to talk about a key security mechanism of UNIX, the set-uid / set-gid privilege.

The Set-uid / Set-gid Privilege

Normally, when you execute a program, a process is created that runs with the privileges associated with your user id. This makes sense; you shouldn't be able to interfere with files or processes belonging to another user. However, some programs need to carry out privileged operations. They can't do this if they execute under the user id of an unprivileged caller. To make a program privileged, the program owner (or root) can assign the set-uid or set-gid bit to the program via the chmod command.

Unlike ordinary programs, a set-uid program executes with the privileges of the program owner—not the caller. By making a program set-uid, you allow it to take actions with the authority of the program owner, on your behalf.

Set-gid works the same way but, not surprisingly, for groups. A set-gid program runs with the privileges of the owning group rather than with the privileges associated with the group of the user id who called the program.

Set-gid can also be set on a directory. Files subsequently created within a set-gid directory will have their group ownership set the same as that of the set-gid directory. Usually the group owner would be set to the users'primary group. This way, a group of users can share data despite being in different primary groups.

An example of a set-uid program is the passwd program. When you change your password, the system needs a way to modify your password entry in / etc / shadow. This file is only accessible by root because it stores passwords; however, this prevents you from legitimately changing your password. By making the passwd program set-uid, you allow a nonprivileged user id to update its password. Without the set-uid bit, users would have to ring up the administrator to have the passwords changed.

In our example, the security of the shadow file is at the mercy of the passwd program. If the user running the password program can somehow influence the program in a way the programmer didn't consider, she might be able to directly modify the shadow file!

Therefore, set-uid programs must be programmed defensively to avoid their being subverted by an attacker to gain extra privileges. In the case of a set-uid root program, the stakes are very high—one exploitable bug will mean game over—the attacker gets root privileges.

The Umask

Our review of file permissions would be incomplete without studying the umask. The umask determines the set of permissions that will apply to a newly created file if no permissions are explicitly specified at creation time. In other words, it's the default file permission.

The umask is represented as the inverse of the file permissions. For example, if our default umask is 022, any files we create in which we don't explicitly set the file permissions will be created with 755 permissions; that is, user id has read, write, and execute permissions, whereas group ID and Other have read and execute permissions. Just remember that the umask should be set to a value opposite of the permissions you want.

A common default umask value is 022. This is usually set in a system-wide login script such as / etc / profile. This can be overridden by a user who specifies a different (usually more restrictive) value in his local login script (for example, ~user / .profile). The umask command is a built-in shell command; it can be run at the shell prompt, for example, as umask 022.

Every process on a UNIX system has a umask setting—it doesn't just affect the users who log in interactively. When the system boots and executes the system start-up scripts, a number of network daemons (services) are started. They inherit the umask value of their parent process init—usually 022. Any files they subsequently create will be given permissions set by the umask unless the programmer explicitly set permissions.

The umask setting is therefore incredibly important—if it is set too loosely, other users might be able to read, or in some cases, write over your files. Despite its importance, it is commonly overlooked by programmers.