Chapter 6 Controlling Access to Files (Tasks)

This chapter describes how to protect files in the Solaris Operating System (Solaris OS). The chapter also describes how to protect the system from files whose permissions could compromise the system.

To protect ZFS files with access control lists (ACLs), see Chapter 8, Using ACLs to Protect Oracle Solaris ZFS Files, in Oracle Solaris ZFS Administration Guide.

The following is a list of the information in this chapter.

• Using UNIX Permissions to Protect Files

• Using Access Control Lists to Protect UFS Files

• Preventing Executable Files From Compromising Security

• Protecting Files (Task Map)

• Protecting Files With UNIX Permissions (Task Map)

• Protecting UFS Files With ACLs (Task Map)

• Protecting Against Programs With Security Risk (Task Map)

Using UNIX Permissions to Protect Files

Files can be secured through UNIX file permissions and through ACLs. Files with sticky bits, and files that are executable, require special security measures.

Commands for Viewing and Securing Files

This table describes the commands for monitoring and securing files and directories.

File and Directory Ownership

Traditional UNIX file permissions can assign ownership to three classes of users:

• 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 the file, to write to the file (make changes to it), or, if the file is a command, to execute the file.

• group – Members of a group of users.

• others – All other users who are not the file owner and are not members of the group.

The owner of the file can usually assign or modify file permissions. Additionally, users or roles with administrative capabilities, such as superuser or the Primary Administrator role, can change a file's ownership. To override system policy, see Example 6–2.

A file can be one of seven types. Each type is displayed by a symbol:

- (Minus symbol)

Text or program

b

Block special file

c

Character special file

d

Directory

l

Symbolic link

s

Socket

D

Door

P

Named pipe (FIFO)

UNIX File Permissions

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

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

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

You can protect the files in a directory and its subdirectories by setting restrictive file permissions on 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: setuid, setgid, and sticky bit. When these permissions are set, any user who runs that executable file assumes the 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 capabilities by executing a program that sets the user ID (UID) to 0, which is the UID of root. Also, all users can set special permissions for files that they own, which constitutes another security concern.

You should monitor your system for any unauthorized use of the setuid permission and the setgid permission to gain superuser capabilities. A suspicious permission grants ownership of an administrative program to a user rather than to root or bin. To search for and list all files that use this special permission, see How to Find Files With Special File Permissions.

setuid Permission

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. The access is not based on the user who is running the executable file. This special permission allows a user to access files and directories that are normally available only to the owner.

For example, the setuid permission on the passwd command makes it possible for users to change passwords. A passwd command with setuid permission would resemble the following:

-r-sr-sr-x   3 root     sys       28144 Jun 17 12:02 /usr/bin/passwd

This special permission presents a security risk. 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.

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, or avoid using the reserved UIDs with setuid permissions.

setgid Permission

The setgid permission is similar to the setuid permission. 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. The /usr/bin/mail command has setgid permissions:

-r-x--s--x   1 root   mail     67504 Jun 17 12:01 /usr/bin/mail

When the setgid permission is applied to a directory, files that were created in this directory belong to the group to which the directory belongs. The files do not belong to 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 that owns the directory, not to the group that the user belongs to.

You should monitor your system for any unauthorized use of the setgid permission to gain superuser capabilities. A suspicious permission grants group access to such a program to an unusual group rather than to root or bin. To search for and list all files that use this permission, see How to Find Files With Special File Permissions.

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 file owner, the directory owner, or by a privileged user. The root user and the Primary Administrator role are examples of privileged users. The sticky bit 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. For instructions, see Example 6–5.

Default umask Value

When you create a file or directory, you create it with a default set of permissions. The system defaults are open. A text file has 666 permissions, which grants read and write permission to everyone. A directory and an executable file have 777 permissions, which grants read, write, and execute permission to everyone. Typically, users override the system defaults in their /etc/profile file, .cshrc file, or .login file.

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

The following table shows some typical umask settings and their effect on an executable file.

For more information on setting the umask value, see the umask(1) man page.

File Permission Modes

The chmod command enables you to change the permissions on a file. You must be superuser or the owner of a file or directory to change its permissions.

You can use the chmod command to set permissions in either of two modes:

• Absolute Mode – Use numbers to represent file permissions. When you change permissions by using the absolute mode, you represent permissions for each triplet by an octal mode number. Absolute mode is the method most commonly used to set permissions.

• Symbolic Mode – Use combinations of letters and symbols to add permissions or remove permissions.

The following table lists the octal values for setting file permissions in absolute mode. You use these numbers in sets of three to set permissions for owner, group, and other, in that order. For example, the value 644 sets read and write permissions for owner, and read-only permissions for group and other.

The following table lists the symbols for setting file permissions in symbolic mode. Symbols can specify whose permissions are to be set or changed, the operation to be performed, and the permissions that are being assigned or changed.

The who operator permissions designations in the function column specify the symbols that change the permissions on the file or directory.

who

Specifies whose permissions are to be changed.

operator

Specifies the operation to be performed.

permissions

Specifies what permissions are to be changed.

You can set special permissions on a file in absolute mode or symbolic mode. However, you must use symbolic mode to set or remove setuid permissions on a directory. In absolute mode, you set special permissions by adding a new octal value to the left of the permission triplet. The following table lists the octal values for setting special permissions on a file.

Using Access Control Lists to Protect UFS Files

Traditional UNIX file protection provides read, write, and execute permissions for the three user classes: file owner, file group, and other. In a UFS file system, an access control list (ACL) provides better file security by enabling you to do the following:

• Define file permissions for the file owner, the group, other, specific users and groups

• Define default permissions for each of the preceding categories

For ACLs in the ZFS file system and ACLs on NFSv4 files, see Chapter 8, Using ACLs to Protect Oracle Solaris ZFS Files, in Oracle Solaris ZFS Administration Guide.

For example, if you want everyone in a group to be able to read a file, you can simply grant 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 does not provide that level of file security. However, an ACL provides this level of file security.

ACL entries define an ACL on a file. On a UFS file system, the entries are set through the setfacl command. UFS ACL entries consist of the following fields separated by colons:

entry-type:[uid|gid]:perms

entry-type

Is the type of ACL entry on which to set file permissions. For example, entry-type can be user (the owner of a file) or mask (the ACL mask). For a listing of ACL entries, see Table 6–7 and Table 6–8.

uid

Is the user name or user ID (UID).

gid

Is the group name or group ID (GID).

perms

Represents the permissions that are set on entry-type. perms can be indicated by the symbolic characters rwx or an octal number. These are the same numbers that are used with the chmod command.

In the following example, an ACL entry sets read and write permissions for the user stacey.

user:stacey:rw-

UFS file system attributes such as ACLs are supported in UFS file systems only. Thus, if you restore or copy files with ACL entries into the /tmp directory, which is usually mounted as a TMPFS file system, the ACL entries will be lost. Use the /var/tmp directory for temporary storage of UFS files.

ACL Entries for UFS Files

The following table lists the valid ACL entries that you might use when setting ACLs on files. The first three ACL entries provide the basic UNIX file protection.

ACL Entries for UFS Directories

In addition to the ACL entries that are described in Table 6–7, you can set default ACL entries on a directory. Files or directories created in a directory that has default ACL entries will have the same ACL entries as the default ACL entries. Table 6–8 lists the default ACL entries for directories.

When you set default ACL entries for specific users and groups on a directory for the first time, you must also set default ACL entries for the file owner, file group, others, and the ACL mask. These entries are required. They are the first four default ACL entries in the following table.

Commands for Administering UFS ACLs

The following commands administer ACLs on UFS files or directories.

setfacl command

Sets, adds, modifies, and deletes ACL entries. For more information, see the setfacl(1) man page.

getfacl command

Displays ACL entries. For more information, see the getfacl(1) man page.

Preventing Executable Files From Compromising Security

A number of security bugs are related to default executable stacks when their permissions are set to read, write, and execute. While stacks with execute permissions are allowed, most programs can function correctly without using executable stacks.

The noexec_user_stack variable enables you to specify whether stack mappings are executable. The variable is available as of the Solaris 2.6 release. By default, the variable is set to zero, except on 64-bit applications, which provides ABI-compliant behavior. If the variable is set to a non-zero value, the system marks the stack of every process in the system as readable and writable, but not executable.

Once this variable is set, programs that attempt to execute code on their stack are sent a SIGSEGV signal. This signal usually results in the program terminating with a core dump. Such programs also generate a warning message that includes the name of the offending program, the process ID, and the real UID of the user who ran the program. For example:

a.out[347] attempt to execute code on stack by uid 555 

The message is logged by the syslog daemon when the syslog kern facility is set to notice level. This logging is set by default in the syslog.conf file, which means that the message is sent to both the console and the /var/adm/messages file. For more information, see the syslogd(1M) and syslog.conf(4) man pages.

The syslog message is useful for observing potential security problems. The message also identifies valid programs that depend upon executable stacks that have been prevented from correct operation by setting this variable. If you do not want any messages logged, then set the noexec_user_stack_log variable to zero in the /etc/system file. Even though messages are not being logged, the SIGSEGV signal can continue to cause the executing program to terminate with a core dump.

You can use the mprotect() function if you want programs to explicitly mark their stack as executable. For more information, see the mprotect(2) man page.

Because of hardware limitations, the capability of catching and reporting executable stack problems is not available on most x86-based systems. Systems in the AMD64 product family can catch and report executable stack problems.

Protecting Files (Task Map)

The following task map points to sets of procedures for protecting files.

Protecting Files With UNIX Permissions (Task Map)

The following task map points to procedures that list file permissions, change file permissions, and protect files with special file permissions.

How to Display File Information

Display information about all the files in a directory by using the ls command.

1. Type the following command to display a long listing of all files in the current directory.

   % ls -la

   -l

   Displays the long format that includes user ownership, group ownership, and file permissions.

   -a

   Displays all files, including hidden files that begin with a dot (.).

Example 6–1 Displaying File Information

In the following example, a partial list of the files in the /sbin directory is displayed.

% cd /sbin
% ls -la
total 13456
drwxr-xr-x   2 root     sys          512 Sep  1 14:11 .
drwxr-xr-x  29 root     root        1024 Sep  1 15:40 ..
-r-xr-xr-x   1 root     bin       218188 Aug 18 15:17 autopush
lrwxrwxrwx   1 root     root          21 Sep  1 14:11 bpgetfile -> ...
-r-xr-xr-x   1 root     bin       505556 Aug 20 13:24 dhcpagent
-r-xr-xr-x   1 root     bin       456064 Aug 20 13:25 dhcpinfo
-r-xr-xr-x   1 root     bin       272360 Aug 18 15:19 fdisk
-r-xr-xr-x   1 root     bin       824728 Aug 20 13:29 hostconfig
-r-xr-xr-x   1 root     bin       603528 Aug 20 13:21 ifconfig
-r-xr-xr-x   1 root     sys       556008 Aug 20 13:21 init
-r-xr-xr-x   2 root     root      274020 Aug 18 15:28 jsh
-r-xr-xr-x   1 root     bin       238736 Aug 21 19:46 mount
-r-xr-xr-x   1 root     sys         7696 Aug 18 15:20 mountall
   .
   .
   .

Each line displays information about a file in the following order:

• Type of file – For example, d. For list of file types, see File and Directory Ownership.

• Permissions – For example, r-xr-xr-x. For description, see File and Directory Ownership.

• Number of hard links – For example, 2.

• Owner of the file – For example, root.

• Group of the file – For example, bin.

• Size of the file, in bytes – For example, 7696.

• Date the file was created or the last date that the file was changed – For example, Aug 18 15:20.

• Name of the file – For example, mountall.

How to Change the Owner of a File

The file owner, the Primary Administrator role, or superuser can change any file's ownership.

1. Display the permissions on a file.

   % ls -l example-file -rw-r--r-- 1 janedoe staff 112640 May 24 10:49 example-file

2. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

3. Change the owner of the file.

   # chown stacey example-file

4. Verify that the owner of the file has changed.

   # ls -l example-file -rw-r--r-- 1 stacey staff 112640 May 26 08:50 example-file

Example 6–2 Enabling Users to Change the Ownership of Files That Others Own

Security Consideration – You should have good reason to override system security policy by changing the setting of the rstchown variable to zero. Any user who accesses the system can change the ownership of any file on the system.

In this example, the value of the rstchown variable is set to zero in the /etc/system file. This setting enables the owner of a file to use the chown command to change the file's ownership to another user. This setting also enables the owner to use the chgrp command to set the group ownership of a file to a group that the owner does not belong to. The change goes into effect when the system is rebooted.

set rstchown = 0

For more information, see the chown(1) and chgrp(1) man pages.

Also, be aware that NFS-mounted file systems have further restrictions on changing ownership and groups. For more information on restricting access to NFS-mounted systems, see Chapter 6, Accessing Network File Systems (Reference), in System Administration Guide: Network Services.

How to Change Group Ownership of a File

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Change the group ownership of a file.

   $ chgrp scifi example-file

   For information on setting up groups, see Chapter 4, Managing User Accounts and Groups (Overview), in System Administration Guide: Basic Administration.

3. Verify that the group ownership of the file has changed.

   $ ls -l example-file -rw-r--r-- 1 stacey scifi 112640 June 20 08:55 example-file

   Also see Example 6–2.

How to Change File Permissions in Symbolic Mode

1. If you are not the owner of the file or directory, become superuser or assume an equivalent role.

   Only the current owner or superuser can use the chmod command to change file permissions on a file or directory.

2. Change permissions in symbolic mode.

   % chmod who operator permissions filename

   who

   Specifies whose permissions are to be changed.

   operator

   Specifies the operation to be performed.

   permissions

   Specifies what permissions are to be changed. For the list of valid symbols, see Table 6–5.

   filename

   Specifies the file or directory.

3. Verify that the permissions of the file have changed.

   % ls -l filename

Example 6–3 Changing Permissions in Symbolic Mode

In the following example, read permission is taken away from others.

% chmod o-r example-file1

In the following example, read and execute permissions are added for user, group, and others.

$ chmod a+rx example-file2

In the following example, read, write, and execute permissions are assigned to group.

$ chmod g=rwx example-file3

How to Change File Permissions in Absolute Mode

1. If you are not the owner of the file or directory, become superuser or assume an equivalent role.

   Only the current owner or superuser can use the chmod command to change file permissions on a file or directory.

2. Change permissions in absolute mode.

   % chmod nnn filename

   nnn

   Specifies the octal values that represent the permissions for the file owner, file group, and others, in that order. For the list of valid octal values, see Table 6–4.

   filename

   Specifies the file or directory.

   ---

   Note –

   When you use the chmod command to change the file group permissions on a file with ACL entries, both the file group permissions and the ACL mask are changed to the new permissions. Be aware that the new ACL mask permissions can change the permissions for other users and groups who have ACL entries on the file. Use the getfacl command to make sure that the appropriate permissions are set for all ACL entries. For more information, see the getfacl(1) man page.

   ---

3. Verify that the permissions of the file have changed.

   % ls -l filename

Example 6–4 Changing Permissions in Absolute Mode

In the following example, the permissions of a public directory are changed from 744 (read, write, execute; read-only; and read-only) to 755 (read, write, execute; read and execute; and read and execute).

# ls -ld public_dir
drwxr--r--  1 ignatz   staff    6023 Aug  5 12:06 public_dir
# chmod 755 public_dir
# ls -ld public_dir
drwxr-xr-x  1 ignatz   staff    6023 Aug  5 12:06 public_dir

In the following example, the permissions of an executable shell script are changed from read and write to read, write, and execute.

% ls -l my_script
-rw------- 1 ignatz   staff    6023 Aug  5 12:06 my_script
% chmod 700 my_script
% ls -l my_script
-rwx------ 1 ignatz   staff    6023 Aug  5 12:06 my_script

How to Change Special File Permissions in Absolute Mode

1. If you are not the owner of the file or directory, become superuser or assume an equivalent role.

   Only the current owner or a user with superuser capabilities can use the chmod command to change the special permissions on a file or directory.

2. Change special permissions in absolute mode.

   % chmod nnnn filename

   nnnn

   Specifies the octal values that change the permissions on the file or directory. The leftmost octal value sets the special permissions on the file. For the list of valid octal values for special permissions, see Table 6–6.

   filename

   Specifies the file or directory.

   ---

   Note –

   When you use the chmod command to change the file group permissions on a file with ACL entries, both the file group permissions and the ACL mask are changed to the new permissions. Be aware that the new ACL mask permissions can change the permissions for additional users and groups who have ACL entries on the file. Use the getfacl command to make sure that the appropriate permissions are set for all ACL entries. For more information, see the getfacl(1) man page.

   ---

3. Verify that the permissions of the file have changed.

   % ls -l filename

Example 6–5 Setting Special File Permissions in Absolute Mode

In the following example, the setuid permission is set on the dbprog file.

# chmod 4555 dbprog
# ls -l dbprog
-r-sr-xr-x   1 db     staff        12095 May  6 09:29 dbprog

In the following example, the setgid permission is set on the dbprog2 file.

# chmod 2551 dbprog2
# ls -l dbprog2
-r-xr-s--x   1 db     staff       24576 May  6 09:30 dbprog2

In the following example, the sticky bit permission is set on the public_dir directory.

# chmod 1777 public_dir
# ls -ld public_dir
drwxrwxrwt   2 ignatz   staff          512 May 15 15:27 public_dir

Protecting UFS Files With ACLs (Task Map)

The following task map points to procedures that list the ACLs on a UFS file, change the ACLs, and copy the ACLs to another file.

How to Check if a File Has an ACL

1. Check if a file has an ACL.

   % ls -l filename

   where filename specifies the file or directory.

   In the output, a plus sign (+) to the right of the mode field indicates that the file has an ACL.

   ---

   Note –

   Unless you have added ACL entries that extend UNIX file permissions, a file is considered to have a “trivial” ACL and the plus sign (+) does not display.

   ---

Example 6–6 Checking if a File Has an ACL

In the following example, the ch1.sgm file has an ACL. The ACL is indicated by the plus sign (+) to the right of the mode field.

% ls -l ch1.sgm
-rwxr-----+  1 stacey   techpubs      167 Nov 11 11:13 ch1.sgm

How to Add ACL Entries to a File

1. Set an ACL on a file by using the setfacl command.

   % setfacl -s user::perms,group::perms,other:perms,mask:perms,acl-entry-list filename ...

   -s

   Sets an ACL on the file. If a file already has an ACL, it is replaced. This option requires at least the user::, group::, and other:: entries.

   user::perms

   Specifies the file owner permissions.

   group::perms

   Specifies the group ownership permissions.

   other:perms

   Specifies the permissions for users other than the file owner or members of the group.

   mask:perms

   Specifies the permissions for the ACL mask. The mask indicates the maximum permissions that are allowed for users (other than the owner) and for groups.

   acl-entry-list

   Specifies the list of one or more ACL entries to set for specific users and groups on the file or directory. You can also set default ACL entries on a directory. Table 6–7 and Table 6–8 show the valid ACL entries.

   filename ...

   Specifies one or more files or directories on which to set the ACL. Multiple filenames are separated by spaces.

   ---

   Caution –

   If an ACL already exists on the file, the -s option replaces the entire ACL with the new ACL.

   ---

   For more information, see the setfacl(1) man page.

2. Verify that the ACL entries were set on the file.

   % getfacl filename

   For more information, see How to Check if a File Has an ACL.

Example 6–7 Setting an ACL on a File

In the following example, the file owner permissions are set to read and write, file group permissions are set to read only, and other permissions are set to none on the ch1.sgm file. In addition, the user anusha is given read and write permissions on the file. The ACL mask permissions are set to read and write, which means that no user or group can have execute permissions.

% setfacl -s user::rw-,group::r--,other:---,mask:rw-,user:anusha:rw- ch1.sgm
% ls -l
total 124
-rw-r-----+  1 stacey  techpubs   34816 Nov 11 14:16 ch1.sgm
-rw-r--r--   1 stacey  techpubs   20167 Nov 11 14:16 ch2.sgm
-rw-r--r--   1 stacey  techpubs    8192 Nov 11 14:16 notes
% getfacl ch1.sgm
# file: ch1.sgm
# owner: stacey
# group: techpubs
user::rw-
user:anusha:rw-    #effective:rw-
group::r--         #effective:r--
mask:rw-
other:---

In the following example, the file owner permissions are set to read, write, and execute, file group permissions are set to read only, other permissions are set to none. In addition, the ACL mask permissions are set to read on the ch2.sgm file. Finally, the user anusha is given read and write permissions. However, due to the ACL mask, the permissions for anusha are read only.

% setfacl -s u::7,g::4,o:0,m:4,u:anusha:7 ch2.sgm
% getfacl ch2.sgm
# file: ch2.sgm
# owner: stacey
# group: techpubs
user::rwx
user:anusha:rwx         #effective:r--
group::r--              #effective:r--
mask:r--
other:---

How to Copy an ACL

1. Copy a file's ACL to another file by redirecting the getfacl output.

   % getfacl filename1 | setfacl -f - filename2

   filename1

   Specifies the file from which to copy the ACL.

   filename2

   Specifies the file on which to set the copied ACL.

Example 6–8 Copying an ACL

In the following example, the ACL on ch2.sgm is copied to ch3.sgm.

% getfacl ch2.sgm | setfacl -f - ch3.sgm

How to Change ACL Entries on a File

1. Modify ACL entries on a file by using the setfacl command.

   % setfacl -m acl-entry-list filename ...

   -m

   Modifies the existing ACL entry.

   acl-entry-list

   Specifies the list of one or more ACL entries to modify on the file or directory. You can also modify default ACL entries on a directory. Table 6–7 and Table 6–8 show the valid ACL entries.

   filename ...

   Specifies one or more files or directories, separated by a space.

2. Verify that the ACL entries were modified on the file.

   % getfacl filename

Example 6–9 Modifying ACL Entries on a File

In the following example, the permissions for the user anusha are modified to read and write.

% setfacl -m user:anusha:6 ch3.sgm
% getfacl ch3.sgm
# file: ch3.sgm
# owner: stacey
# group: techpubs
user::rw-				
user::anusha:rw-        #effective:r--
group::r-               #effective:r--
mask:r--
other:r-

In the following example, the default permissions for the group staff are modified to read on the book directory. In addition, the default ACL mask permissions are modified to read and write.

% setfacl -m default:group:staff:4,default:mask:6 book

How to Delete ACL Entries From a File

1. Delete ACL entries from a file.

   % setfacl -d acl-entry-list filename ...

   -d

   Deletes the specified ACL entries.

   acl-entry-list

   Specifies the list of ACL entries (without specifying the permissions) to delete from the file or directory. You can only delete ACL entries and default ACL entries for specific users and groups. Table 6–7 and Table 6–8 show the valid ACL entries.

   filename ...

   Specifies one or more files or directories, separated by a space.

   Alternatively, you can use the setfacl -s command to delete all the ACL entries on a file and replace them with the new ACL entries that are specified.

2. Verify that the ACL entries were deleted from the file.

   % getfacl filename

Example 6–10 Deleting ACL Entries on a File

In the following example, the user anusha is deleted from the ch4.sgm file.

% setfacl -d user:anusha ch4.sgm

How to Display ACL Entries for a File

1. Display ACL entries for a file by using the getfacl command.

   % getfacl [-a | -d] filename ...

   -a

   Displays the file name, file owner, file group, and ACL entries for the specified file or directory.

   -d

   Displays the file name, file owner, file group, and the default ACL entries, if they exist, for the specified directory.

   filename ...

   Specifies one or more files or directories, separated by a space.

   If you specify multiple file names on the command line, the ACL entries are displayed with a blank line between each entry.

Example 6–11 Displaying ACL Entries for a File

In the following example, all the ACL entries for the ch1.sgm file are displayed. The #effective: note beside the user and group entries indicates what the permissions are after being modified by the ACL mask.

% getfacl ch1.sgm

# file: ch1.sgm
# owner: stacey
# group: techpubs
user::rw-
user:anusha:r-        #effective:r--
group::rw-            #effective:rw-
mask:rw-
other:---

In the following example, the default ACL entries for the book directory are displayed.

% getfacl -d book

# file: book
# owner: stacey
# group: techpubs
user::rwx
user:anusha:r-x       #effective:r-x
group::rwx            #effective:rwx
mask:rwx
other:---
default:user::rw-
default:user:anusha:r--
default:group::rw-
default:mask:rw-
default:other:---

Protecting Against Programs With Security Risk (Task Map)

The following task map points to procedures that find risky executables on the system, and that prevent programs from exploiting an executable stack.

How to Find Files With Special File Permissions

You should monitor your system for any unauthorized use of the setuid and setgid permissions on programs. The setuid and setgid permissions enable ordinary users to gain superuser capabilities. A suspicious executable file grants ownership to a user rather than to root or bin.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Find files with setuid permissions by using the find command.

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

   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.

   >/tmp/filename

   Is the file that contains the results of the find command.

3. Display the results in /tmp/filename.

   # more /tmp/filename

   For background information on setuid permissions, see setuid Permission.

Example 6–12 Finding Files With setuid Permissions

The output from the following example shows that a user named rar has made a personal copy of /usr/bin/sh, and has set the permissions as setuid to root. As a result, the /usr/rar/bin/sh program runs with root permissions.

This output was saved for future reference by moving the file out of the /tmp directory.

# find / -user root -perm -4000 -exec ls -ldb {} \; > /var/tmp/ckprm
# cat /var/tmp/ckprm
-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
# mv /var/tmp/ckprm /export/sysreports/ckprm

How to Disable Programs From Using Executable Stacks

For a description of the security risks of executable stacks, see Preventing Executable Files From Compromising Security.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Edit the /etc/system file, and add the following line:

   set noexec_user_stack=1

3. Reboot the system.

   # init 6

Example 6–13 Disabling the Logging of Executable Stack Messages

In this example, the logging of executable stack messages is disabled, and then the system is rebooted.

# cat /etc/system
set noexec_user_stack=1
set noexec_user_stack_log=0
# init 6