Controlling File Access

After you have established login restrictions, you need to control access to the data on the system. Some users only need to look at files; others need the ability to change or delete files. You might have data that you do not want anyone else to see. You control data access by assigning permission levels to a file or directory.

Three levels of access permission are assigned to a UNIX file to control access by the owner, the group, and all others. Display permissions with the ls -la command. The following example shows the use of the ls -la command to display permissions on files in the /users directory:

ls -la    /users 

The system responds with this:

drwxr-xr-x   2   bill   staff   512    Sep 23 07:02         . 
drwxr-xr-x   3   root   other   512    Sep 23 07:02         .. 
-rw-r--r--   1   bill   staff   124    Sep 23 07:02         .cshrc 
-rw-r--r--   1   bill   staff   575    Sep 23 07:02         .login 

The first column of information displays the type of file and its access permissions for the user, group, and others. The r, w, and x are described in Table 16.6. The third column displays the owner of the file—usually the user who created the file. The owner of a file (and superuser) can decide who has the right to read it, to write to it, and—if it is a command—to execute it. The fourth column displays the group to which this file belongs—normally the owner’s primary group.

When listing the permissions on a directory, all columns of information are the same as for a file, with one exception. The r, w, and x found in the first column are treated slightly differently than for a file. They are described in Table 16.7.

Use the commands listed in Table 16.8 to modify file access permissions and ownership, but remember that only the owner of the file or root can assign or modify these values.

Effective User ID and Group ID

The su (switch user) command enables a user to become another user without logging off the system. To use the su command, you must supply the password for the user you are attempting to log in as, unless you are already logged in as root. The root user can run su without being prompted for passwords.

System administrators often use the su command. For example, as a safety precaution, rather than using the superuser password as a regular login, a system administrator might use a regular, nonroot login whenever he is not performing administration functions. When root access is required, the system administrator quickly switches to superuser using the su command. When the administrator is finished performing the task, he exits the superuser account and continues working using his normal, nonroot account.

If the user enters the correct password, su creates a new shell process as specified in the shell field of the /etc/passwd file for that particular user. In the following example, user1 runs the su command to become user2:

su user2 

An option to the su command is – (dash). This option specifies a complete login. The specified user’s .profile is run and the environment is changed to what would be expected if the user actually logged in as the specified user.

Without the -, the environment is passed along from the original login, with the exception of $PATH, which is controlled by PATH and SUPATH in the /etc/default/su file described later in this chapter.

Default umask

When a user creates a file or directory, the user mask controls the default file permissions assigned to the file or directory. The umask command should set the user mask in a user initialization file, such as /etc/profile or .cshrc. You can display the current value of the user mask by typing umask and pressing Enter.

The user mask is set with a three-digit octal value, such as 022. The first digit sets permissions for the user, the second sets permissions for the group, and the third sets permissions for others. To set the umask to 022, type the following:

umask 022 

By default, the system sets the permissions on a file to 666, granting read and write permission to the user, group, and others. The system sets the default permissions on a directory or executable file to 777, or rwxrwxrwx. The value assigned by umask is subtracted from the default. To determine the umask value that you want to set, subtract the value of the permissions you want from 666 (for a file) or 777 (for a directory). The remainder is the value to use with the umask command. For example, suppose you want to change the default mode for files to 644 (rw-r--r--). The difference between 666 and 644 is 022, which is the value you would use as an argument to the umask command.

Setting the umask value has the effect of granting or denying permissions in the same way that chmod grants them. For example, the command chmod 022 grants write permission to group and others, and umask 022 denies write permission to group and others.

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 root. This prevents a user from deleting other users’ files from public directories. A t or T in the access permissions column of a file listing indicates that the sticky bit has been set, as shown here:

drwxrwxrwt   2 uucp   uucp   512 Feb 12 07:32 /var/spool/uucppublic 

Use the chmod command to set the sticky bit. The symbols for setting the sticky bit by using the chmod command in symbolic mode are listed in Table 16.9.

Access Control Lists (ACLs)

ACLs (pronounced ackls) can provide greater control over file permissions when the traditional UNIX file protection in the Solaris operating system is not enough. The traditional UNIX file protection provides read, write, and execute permissions for the three user classes: owner, group, and other. An ACL provides better file security by enabling you to define file permissions for the owner, owner’s group, others, specific users and groups, and default permissions for each of these categories.

For example, assume that you have a file that you want everyone in a group to be able to read. To give everyone access, you would give group read permissions on that file. Now, assume that you want only one person in the group to be able to write to that file. Standard UNIX doesn’t let you set that up; however, you can set up an ACL to give only one person in the group write permissions on the file. Think of ACL entries as an extension to regular UNIX permissions.

ACL entries are the way to define an ACL on a file, and they are set through the ACL commands. ACL entries consist of the following fields, separated by colons:

							entry_type:uid|gid:perms
						

ACL entries are defined in Table 16.10.

The ACL mask entry indicates the maximum permissions allowed for users other than the owner and for groups. The mask is a quick way to change permissions on all users and groups. For example, the mask:r-- mask entry indicates that users and groups cannot have more than read permissions, even though they might have write/execute permissions.

Setting ACL Entries

Set ACL entries on a file by using the setfacl command:

$ setfacl -s user::perms,group::perms,other:perms,mask:perms,acl_entry_list filename 
... 

The -s option replaces the entire ACL with the new ACL entries if an ACL already exists on the file.

The following example sets the user permissions to read/write, group permissions to read-only, and other permissions to none on the txt1.doc file. In addition, the user bill is given read/write permissions on the file, and the ACL mask permissions are set to read/write, which means that no user or group can have execute permissions.

$ setfacl -s user::rw-,group::r--,other:---,mask:rw-,user:bill:rw- txt1.doc 

In addition to the ACL entries for files, you can set default ACL entries on a directory that apply to files created within the directory. For example, I’ll use the setfacl command to set execute privileges on the /home/bholzgen directory for user bcalkins. Execute privileges on a directory enable a user to change to that directory and do a long listing with the ls -l command on that directory. Before I set the ACL on this directory, let’s look at the default permission that currently exists on that directory:

drwxr-xr-x   2 bholzgen   staff    512 Jul 30 12:41 bholzgen 

Now issue the command to set the ACL privileges:

setfacl -s user::rwx,g::r--,o:---,m:rwx,user:bcalkins:rwx /export/home/bholzgen 

Use the getfacl command to display the ACL entry for the /export/home/ bholzgen directory, as follows:

getfacl /export/home/bholzgen 

The system responds with the following:

# file: /export/home/bholzgen 
# owner: bholzgen 
# group: staff 
user::rwx 
user:bcalkins:rwx               #effective:rwx 
group::r--              #effective:r--
mask:rwx 
other:---

Now, the only persons allowed to change into the /export/home/bholzgen directory are bholzgen and bcalkins. No other members, except root, can access this directory—not even members of the same group.

Checking the New File Permissions

Check the new file permissions with the ls -l command. The plus sign (+) to the right of the mode field indicates that the file has an ACL:

$ ls -l 
 total 210 
 -rw-r-----+   1 mike  sysadmin   32100  Sep 11 13:11 txt1.doc 
 -rw-r--r--    1 mike  sysadmin   1410   Sep 11 13:11 txt2.doc 
 -rw-r--r--    1 mike  sysadmin   1700   Sep 11 13:11 labnotes

Verifying ACL Entries

To verify which ACL entries were set on the file, use the getfacl command:

$ getfacl txt1.doc 

The system responds with this:

# file: txt1.doc 
# owner: mike 
# group: sysadmin 
user::rw-
user:bill:rw-      #effective:rw-
group::r--         #effective:r--
mask:rw-
other:---

Copying a File’s ACL to Another File

Copy a file’s ACL to another file by redirecting the getfacl output, as follows:

getfacl <filename1>: | setfacl  -f  -  <filename2> 

In the following example, I copy the ACL from file1 to file2:

getfacl file1 | setfacl -f - file2 

Issuing the getfacl command, I can verify that the change has been made:

getfacl file* 

# file: file1 
# owner: root 
# group: other 
user::rw-
user:bcalkins:rw-               #effective:rw-
group::r--              #effective:r--
mask:rw-
other:---

# file: file2 
# owner: root 
# group: other 
user::rw-
user:bcalkins:rw-               #effective:rw-
group::r--              #effective:r--
mask:rw-
other:---

Modifying ACL Entries on a File

Modify ACL entries on a file by using the setfacl command:

setfacl -m <acl_entry_list> <filename1> [filename2 ...] 

The arguments for the setfacl command are described in Table 16.11.

The ACL entries that can be specified with the setfacl command are described in Table 16.12.

Deleting ACL Entries from a File

To delete an ACL entry from a file, use the setfacl -d <acl_entry_list> command. The following example illustrates how to remove an ACL entry for user bcalkins on file1 and file2:

setfacl -d u:bcalkins file1 file2 

Use the getfacl command, described earlier, to verify that the entries have been deleted.

Setting the Correct Path

Setting your path variable correctly is important; otherwise, you might accidentally run a program introduced by someone else that harms the data or your system. This kind of program, which creates a security hazard, is called a Trojan horse. For example, a substitute su program could be placed in a public directory where you, as system administrator, might run it. Such a script would look just like the regular su command. The script would remove itself after execution, and you would have trouble knowing that you actually ran a Trojan horse.

The path variable is automatically set at login time through the startup files .login, .profile, and .cshrc. Setting up the user search path so that the current directory (.) comes last prevents you and your users from running this type of Trojan horse. The path variable for superuser should not include the current directory (.).

The setuid and setgid Programs

When set-user identification (setuid) permission is set on an executable file, a process that runs the file is granted access based on the file’s owner (usually root) rather than the user who created the process. This enables a user to access files and directories that normally are available only to the owner. For example, the setuid permission on the passwd command makes it possible for a user to edit the /etc/passwd file to change passwords. When a user executes the passwd command, that user assumes the permissions of the root ID, which is UID 0. The setuid permission can be identified by using the ls -l command. The s in the permissions field of the following example indicates the use of setuid:

ls -l /usr/bin/passwd 
  -r-sr-sr-x   1 root     sys    10332 May  3 08:23 /usr/bin/passwd 

Many executable programs must be run as root (that is, as superuser) to work properly. These executables run with the user ID set to 0 (setuid=0). Anyone running these programs runs them with the root ID, which creates a potential security problem if the programs are not written with security in mind.

On the other hand, the use of setuid on an executable program presents a security risk. A determined user can usually find a way to maintain the permissions granted to him by the setuid process, even after the process has finished executing. For example, a particular command might grant root privileges through the setuid. If a user can break out of this command, he could still have the root privileges granted by the setuid on that file. An intruder who accesses a system will look for any files that have the setuid bit enabled.

Except for the executables shipped with Solaris that have their setuid to root, you should disallow the use of setuid programs—or at least restrict and keep them to a minimum. A good alternative to using setuid on programs is to use RBAC, which is described in Chapter 17.

# find [directory] -user root -perm -4000 -exec ls -ldb {} ; >/tmp/filename 

The set-group identification (setgid) permission is similar to setuid, except that the process’s effective GID is changed to the group owner of the file and a user is granted access based on permissions granted to that group. Using the ls -l command, you can see that the file /usr/bin/mail has setgid permissions:

-r-x--s--x   1 bin   mail   61076 Nov  8 2001  /usr/bin/mail 

The following example illustrates how to set the UID on an executable file named myprog1:

chmod 4744  myprog1 

Verify the change by typing the following:

ls -l myprog1 

The system responds with this:

-rwsr--r--   1   root   other   25   Mar   6   11:52   myprog1 

The following example illustrates how to set the GID on an executable file named myprog1:

chmod 2070 myprog1 

Verify the change by typing the following:

ls -l myprog1 

The system responds with this:

----rws---   1   root   other   25   Mar   6   11:58   myprog1 

A user can set the UID or GID permission for any file he owns.