Listing and Securing Files and Directories

We'll be concerned with four commands used for listing and securing files and directories from the command line:

• ls  List files and some information about the files contained within a directory.

• chown  Change user ownership of a file.

• chgrp  Change group ownership of a file.

• chmod  Change permissions on a file.

The ls command supports several options—for a complete list, see its man page. Perhaps the most commonly used option is -l for long listing, which is used to see file permissions and other information. Here's an example using the command:

$ ls -l
total 5722
-rwxrwxrwx+  1 b_jones  dev     10876 Sep 8 9:00 sample
-rw-r--r--   1 root     other   549722 Sep 9 10:49 1
-rw-r--r--   1 root     other   255246 Sep 13 15:14 10-1
-rw-r--r--   1 root     other   549722 Sep 9 10:49 2
-rw-r--r--   1 root     other   533622 Sep 9 10:49 3
-rw-r--r--   1 root     other   549722 Sep 9 13:54 9-4
-rw-r--r--   1 root     other   400472 Sep 9 13:55 9-5
-rw-r--r--   1 j_chirillo root      1772 Sep  9 10:47 cdkeydl
drwxr-xr-x   2 j_chirillo root       512 Sep 13 15:43 dioc
drwxr-xr-x   2 j_chirillo root       512 Sep 13 15:43 docs

Take a look at this output from right to left. You see that the current directory holds several files. Let's focus on the first file, sample. We see the last time that file's contents were modified was 9:00 A.M. on September 8. The file contains 10,876 characters, or bytes. The owner of the file, or the user, belongs to the group dev (the development group), and his or her login name is b_jones. The number, in this case 1, indicates the number of links to the file sample. The plus sign indicates that an ACL is associated with the file. Finally, the dash and letters at the front of the line tell you that user, group, and others have permissions to read, write, and execute sample. The execute (x) symbol here occupies the third position of the three- character sequence. A - in the third position would have indicated a denial of execution permissions. Following are definitions of the permissions:

• r  The file is readable.

• w  The file is writable.

• x  The file is executable.

• -  The indicated permission is not granted.

• s  The set-user-ID or set-group-ID bit is on, and the corresponding user or group execution bit is also on.

• S  The undefined bit state (the set-user-ID bit) is on and the user execution bit is off.

• t  The 1000 (octal) bit, or sticky bit, is on—see chmod(1)—and execution is on.

• T  The 1000 bit is turned on, and execution is off (undefined bit state).

The chown command is used to change file ownership. It will set the user ID of the file named by each file to the user ID specified by owner and, optionally, will set the group ID to that specified by group. If chown is invoked by other than the superuser, the set-user-ID bit is cleared. Only the owner of a file (or the superuser) may change the owner of that file. The syntax of chown is chown [-fhR] owner [:group] file. Following are the options you can use with the chown command:

• -f Do not report errors.

• -h If the file is a symbolic link, change the owner of the symbolic link. Without this option, the owner of the file referenced by the symbolic link is changed.

• -R Recursive. The chown command descends through the directory and any subdirectories, setting the ownership ID as it proceeds. When a symbolic link is encountered, the owner of the target file is changed (unless the -h option is specified), but no recursion takes place.

Let's look at an example of the chown command. We'll change the owner of our sample file to j_chirillo:

chown j_chirillo sample

If we list the directory contents in long format, here's what we'll get:

$ ls -l
total 5722
-rwxrwxrwx+  1 j_chirillo dev      10876  Sep 8 9:00 sample
-rw-r--r--   1 root     other    549722 Sep  9 10:49 1
-rw-r--r--   1 root     other    255246 Sep 13 15:14 10-1
-rw-r--r--   1 root     other    549722 Sep  9 10:49 2
-rw-r--r--   1 root     other    533622 Sep  9 10:49 3
-rw-r--r--   1 root     other    549722 Sep  9 13:54 9-4
-rw-r--r--   1 root     other    400472 Sep  9 13:55 9-5
-rw-r--r--   1 j_chirillo root       1772 Sep 9 10:47 cdkeydl
drwxr-xr-x   2 j_chirillo root       512 Sep 13 15:43 dioc
drwxr-xr-x   2 j_chirillo root       512 Sep 13 15:43 docs

The chgrp command is used to change group ownership of a file and has the same options as the chown command. This command will set the group ID of the file named by each file operand to the group ID specified by the group operand. For each file operand, chgrp will perform actions equivalent to the chown function, called with the following arguments:

• The file operand will be used as the path argument.

• The user ID of the file will be used as the owner argument.

• The specified group ID will be used as the group argument.

Unless chgrp is invoked by a process with appropriate privileges, the set-user-ID and set-group-ID bits of a regular file will be cleared upon successful completion; the set-user-ID and set-group-ID bits of other file types may be cleared.

The most powerful command—with regard to this chapter—of the group we mentioned in this section is the chmod command. The command changes or assigns the mode of a file (permissions and other attributes), which may be absolute or symbolic. An absolute mode is specified using octal numbers, in this format: chmod nnnn file; where n is a number from 0 to 7. The octal numbers used are listed here:

• 4000  Set user ID on execution.

• 20#0  Set group ID on execution if # is 7, 5, 3, or 1. Enable mandatory locking if # is 6, 4, 2, or 0.

• 1000  Turn on sticky bit. The sticky bit protects files within a directory in that a file can be deleted only by the owner or privileged user.

• 0400  Allow read by owner.

• 0200  Allow write by owner.

• 0100  Allow execute (search in directory) by owner.

• 0700  Allow read, write, and execute (search) by owner.

• 0040  Allow read by group.

• 0020  Allow write by group.

• 0010  Allow execute (search in directory) by group.

• 0070  Allow read, write, and execute (search) by group.

• 0004  Allow read by others.

• 0002  Allow write by others.

• 0001  Allow execute (search in directory) by others.

• 0007  Allow read, write, and execute (search) by others.

A chmod symbolic mode uses the following format: chmod <symbolic-mode-list> file; where <symbolic-mode-list> is a comma-separated list (with no intervening white space) of symbolic mode expressions of the form [who] operator [permissions]. Here, who can be u, g, o, and a, specifying whose permissions are to be changed or assigned:

• u  User's permissions

• g  Group's permissions

• o  Others' permissions

• a  All permissions (user, group, and other)

The operator is either +, -, or = signifying how permissions are to be changed:

• +  Add permissions.

• -  Take away permissions.

• =  Assign permissions absolutely.

The permissions are any compatible combination of the following letters:

• r   Read permission.

• w  Write permission.

• x  Execute permission.

• l  Mandatory locking.

• s  User- or group-set-ID.

• t  Sticky bit.

• u, g, o  Permission is to be taken from the current user, group, or other mode, respectively.

You can use the chmod command to set permissions in absolute mode, which uses numbers to represent file permissions, or symbolic mode, which uses combinations of letters and symbols to add permissions or remove permissions.

Set-Group-ID and Set-User-ID

On occasion, a user who is not the owner of a file may need permission to execute the file. For example, to grant a user the ability to change passwords, that user will require permission to use the passwd command. Executable files and public directories can be assigned special permissions that, upon execution, will allow the user to assume the ID of the owner or group. These are the setuid (set-user-ID) and setgid (set-group-ID) permissions.

When setuid permission is set on an executable file, a process that runs this file is granted access on the basis of the owner of the file. In other words, since it is not based on the user, the setuid permission allows a user to access files and directories that are normally available only to the owner. This permission presents a security risk, as attackers can find a way to maintain the permissions that are granted to them by the setuid process, even after the process has finished executing.

Exam Watch

For the exam, you'll need to know the values in the following list, which better explains the values for setting file permissions in absolute mode: Value = 0, permission set = --- for no permissions Value = 1, permission set = --x for execute permission only Value = 2, permission set = -w- for write permission only Value = 3, permission set = -wx for write and execute permissions Value = 4, permission set = r-- for read permission only Value = 5, permission set = r-x for read and execute permissions Value = 6, permission set = rw- for read and write permissions Value = 7, permission set = rwx for read, write, and execute permissions You use these numbers in sets of three, which set permissions for owner, group, and other, in that order only. Let's look at some examples of the chmod command: To deny the execute permission of our sample file to everyone, use chmod a-x sample. To allow only read permission of our sample file to everyone, use chmod 444 sample. To allow everyone to read, write, and execute the sample file and turn on the set group-ID, use chmod a=rwx,g+s sample and then chmod 2777 sample. The value 644 sets read and write permissions for owner, and read-only permissions for group and other.

The setgid permission is similar to the setuid permission in that the process's effective group ID (GID) is changed to the group that owns the file, and a user is granted access based on the permissions that are granted to that group. When the permission is applied to a directory, files that were created in this directory belong to the group to which the directory belongs.

You should monitor your system for any unauthorized use of the setgid and setuid permissions. According to Sun, a suspicious permission grants program access to an unusual group rather than to root or bin. Sun recommends that you always monitor programs that are executed with privileges as well as the users that have rights to execute them. To do so, you can search your system for unauthorized use of the setuid and setgid permissions on programs to gain superuser privileges. In a terminal session with superuser privileges, search for files with setuid permissions by using the find command, like so:

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

where find directory checks all mounted paths starting at the specified directory, which can be root (/), sys, bin, or mail; -user root displays files owned only by root; -perm -4000 displays files only with permissions set to 4000; -exec ls -ldb displays the output of the find command in ls -ldb format; and >/tmp/filename writes results to this file.

Following is a sample of output you can expect to see while finding files with setuid permissions:

-r-sr-xr-x 1 root bin 38836 Aug 10 16:16 /usr/bin/at
-r-sr-xr-x 1 root bin 19812 Aug 10 16:16 /usr/bin/crontab
---s--x--x 1 root sys 46040 Aug 10 15:18 /usr/bin/ct
-r-sr-xr-x 1 root sys 12092 Aug 11 01:29 /usr/lib/mv_dir
-r-sr-sr-x 1 root bin 33208 Aug 10 15:55 /usr/lib/lpadmin
-r-sr-sr-x 1 root bin 38696 Aug 10 15:55 /usr/lib/lpsched
---s--x--- 1 root rar 45376 Aug 18 15:11 /usr/rar/bin/sh
-r-sr-xr-x 1 root bin 12524 Aug 11 01:27 /usr/bin/df
-rwsr-xr-x 1 root sys 21780 Aug 11 01:27 /usr/bin/newgrp
-r-sr-sr-x 1 root sys 23000 Aug 11 01:27 /usr/bin/passwd
-r-sr-xr-x 1 root sys 23824 Aug 11 01:27 /usr/bin/su

Exam Watch

For the exam, it's important to know what happens when the setuid permission is set on an executable file, which enables a process that runs this file to be granted access on the basis of the owner of the file. As a result, this permission presents a security risk as attackers can find a way to maintain the permissions that are granted to them by the setuid process even after the process has finished executing.

Exercise 10-1: Find Files with setuid Permissions

In this exercise, we use the find command to locate files with setuid permissions and then view the results with the more command.

Using the find Command to Locate Files with setuid Permissions

1. Log in with an account that has root privileges so you'll have full privileges that may be required to search all files.

2. Search for files with setuid permissions with the find command:

   find directory -user root -perm -4000 -exec ls -ldb {} \; >/dump/results
   

Viewing the Results

3. View the results in /dump/results using the more command:

   more /dump/results

   where results is the name of the file in the /dump directory to which you wrote your find results.

For added security—by preventing executable files from compromising the system—you can disable programs from using executable stacks. In the Solaris operating system, the noexec_user_stack variable gives you the option of allowing or disallowing executable stack mappings. In other words, by executing a simple command, you can mitigate your risk to program stack buffer overflows with extra data that can be executed. If the noexec_user_stack variable is set to non-zero (the variable is set to zero by default), the operating system will apply nonexecutable but readable and writable attributes to every process stack.

When you disallow executable stacks, programs that attempt to execute code on their stack will abort with a core dump. At that time, a warning message will be displayed with the name of the program, its process ID, and the UID of the user who ran the program. In addition, the message can be logged by syslog when the syslog kern facility is set to notice level (refer to Chapter 4 for more information on logging and using syslog). But because of hardware limitations, monitoring and reporting executable stacks is available only on microSPARC (sun4m) and UltraSPARC (sun4u) platforms.

Inside The Exam–Disabling Executable Stacks

Although most programs will run smoothly without running code from the stack, it's important to note that some software may require executable stacks. Therefore, if you disable executable stacks, programs that require an executable stack will be aborted; it's crucial to test this procedure first on a non-production system.

Following are steps for manually disabling programs from using executable stacks:

1. Assume the role of superuser.

2. Change the directory to the /etc folder and begin to edit the system file (/etc/system).

3. Type cd /etc, press ENTER, and then type vi system and press ENTER again.

4. In the visual editor, press the I key (to switch to edit mode and insert text) and type set noexec_user_stack=1, and then press ENTER.

5. Press the ESC key (to enter into command mode) and type :wq; then press ENTER to save and exit.

6. At the terminal prompt, reboot the system by typing the command init 6 and then pressing ENTER.

You can disable or enable executable stack message logging. If enabled, when a program attempts to execute stack code, the attempt will be logged by syslog. To enable message logging, follow these steps:

1. Assume the role of superuser.

2. Edit the /etc/system file and add set noexec_user_stack_log=1.

3. Reboot the system.

Conversely, to disable executable stack message logging, add set noexec_user_stack_log=0 to the etc/system file and reboot the system.

Exam Watch

You should always monitor the system for unauthorized setuid and setgid permissions to gain superuser privileges.

Exercise 10-2: Disable Executable Stacks and Enable Stack Message Logging

In this exercise, we disable executable stacks and enable stack message logging in the /etc/system file; then we reboot the operating system to initiate the changes.

Disabling Executable Stacks

1. Log in with an account that has root privileges or become superuser.

2. Change the directory to the /etc folder and edit the system file in your favorite editor.

3. Type set noexec_user_stack=1.

Enabling Stack Message Logging

4. While editing the /etc/system file, add set noexec_user_stack_log=1.

5. Save the changes and exit the editor.

Rebooting the Operating System

6. Restart the server.

Using the Desktop Environment to Change Standard File Permissions

You can use the Solaris desktop environment to view and modify file permissions. Perhaps the easiest way to do so is by opening the File Manager, right-clicking a file for which you are the owner, and selecting Properties from the File menu. This should open a file properties interface similar to that shown in Figure 10-1. You probably noticed the Show Access Control List button on the file properties interface. You can view and modify ACLs graphically as well, which we'll cover in the next section.

Figure 10-1: Managing file permissions from the file properties interface

In particular, notice the Basic Permissions section of the file properties interface. You can set permissions on a file or folder, including Read Permission, which allows access to retrieve, copy, or view the contents of the object; Write Permission, which allows access to change the contents of the file and to create or delete objects from the folder; and Execute Permission, which allows access to run the file (for executable files, scripts, and actions) and search and lists the folder's contents. For example, to grant permissions on a file for everyone to use, but to protect it so it cannot be overwritten, click to change the file's properties, giving read and execute permission to Owner, Group, and Other, but giving no one write permission.