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.
Files can be secured through UNIX file permissions and through ACLs. Files with sticky bits, and files that are executable, require special security measures.
This table describes the commands for monitoring and securing files and directories.
Table 6–1 Commands for Securing Files and Directories
Command |
Description |
Man Page |
---|---|---|
Lists the files in a directory and information about the files. | ||
Changes the ownership of a file. | ||
Changes the group ownership of a file. | ||
Changes permissions on a file. You can use either symbolic mode, which uses letters and symbols, or absolute mode, which uses octal numbers, to change permissions on a file. |
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:
Block special file
Character special file
Directory
Symbolic link
Socket
Door
Named pipe (FIFO)
The following table lists and describes the permissions that you can give to each class of user for a file or directory.
Table 6–2 File and Directory Permissions
Symbol |
Permission |
Object |
Description |
---|---|---|---|
r |
Read |
File |
Designated users can open and read the contents of a file. |
|
|
Directory |
Designated users can list files in the directory. |
w |
Write |
File |
Designated users can modify the contents of the file or delete the file. |
|
|
Directory |
Designated users can add files or add links in the directory. They can also remove files or remove links in the directory. |
x |
Execute |
File |
Designated users can execute the file, if it is a program or shell script. They also can run the program with one of the exec(2) system calls. |
|
|
Directory |
Designated users can open files or execute files in the directory. They also can make the directory and the directories beneath it current. |
- |
Denied |
File and Directory |
Designated users cannot read, write, or execute the file. |
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.
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.
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.
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.
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.
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.
Table 6–3 umask Settings for Different Security Levels
Level of Security |
umask Setting |
Permissions Disallowed |
---|---|---|
Permissive (744) |
022 |
w for group and others |
Moderate (740) |
027 |
w for group, rwx for others |
Moderate (741) |
026 |
w for group, rw for others |
Severe (700) |
077 |
rwx for group and others |
For more information on setting the umask value, see the umask(1) man page.
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.
Table 6–4 Setting File Permissions in Absolute Mode
Octal Value |
File Permissions Set |
Permissions Description |
---|---|---|
0 |
--- |
No permissions |
1 |
--x |
Execute permission only |
2 |
-w- |
Write permission only |
3 |
-wx |
Write and execute permissions |
4 |
r-- |
Read permission only |
5 |
r-x |
Read and execute permissions |
6 |
rw- |
Read and write permissions |
7 |
rwx |
Read, write, and execute permissions |
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.
Table 6–5 Setting File Permissions in Symbolic Mode
Symbol |
Function |
Description |
---|---|---|
u |
who |
User (owner) |
g |
who |
Group |
o |
who |
Others |
a |
who |
All |
= |
operator |
Assign |
+ |
operator |
Add |
- |
operator |
Remove |
r |
permissions |
Read |
w |
permissions |
Write |
x |
permissions |
Execute |
l |
permissions |
Mandatory locking, setgid bit is on, group execution bit is off |
s |
permissions |
setuid or setgid bit is on |
t |
permissions |
Sticky bit is on, execution bit for others is on |
The who operator permissions designations in the function column specify the symbols that change the permissions on the file or directory.
Specifies whose permissions are to be changed.
Specifies the operation to be performed.
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.
Table 6–6 Setting Special File Permissions in Absolute Mode
Octal Value |
Special File Permissions |
---|---|
1 |
Sticky bit |
2 |
setgid |
4 |
setuid |
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 |
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.
Is the user name or user ID (UID).
Is the group name or group ID (GID).
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.
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.
Table 6–7 ACL Entries for UFS Files
ACL Entry |
Description |
---|---|
u[ser]::perms |
File owner permissions. |
g[roup]::perms |
File group permissions. |
o[ther]:perms |
Permissions for users other than the file owner or members of the file group. |
m[ask]:perms |
The ACL mask. The mask entry indicates the maximum permissions that are allowed for users (other than the owner) and for groups. The mask is a quick way to change permissions on all the users and groups. For example, the mask:r-- mask entry indicates that users and groups cannot have more than read permissions, even though their accounts state that they have write and execute permissions. |
u[ser]:uid:perms |
Permissions for a specific user. For uid, you can specify either a user name or a numeric UID. |
g[roup]:gid:perms |
Permissions for a specific group. For gid, you can specify either a group name or a numeric GID. |
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.
Table 6–8 Default ACL Entries for UFS Directories
Default ACL Entry |
Description |
---|---|
d[efault]:u[ser]::perms |
Default file owner permissions. |
d[efault]:g[roup]::perms |
Default file group permissions. |
d[efault]:o[ther]:perms |
Default permissions for users other than the file owner or members of the file group. |
d[efault]:m[ask]:perms |
Default ACL mask. |
d[efault]:u[ser]:uid:perms |
Default permissions for a specific user. For uid, you can specify either a user name or a numeric UID. |
d[efault]:g[roup]:gid:perms |
Default permissions for a specific group. For gid, you can specify either a group name or a numeric GID. |
The following commands administer ACLs on UFS files or directories.
Sets, adds, modifies, and deletes ACL entries. For more information, see the setfacl(1) man page.
Displays ACL entries. For more information, see the getfacl(1) man page.
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.
The following task map points to sets of procedures for protecting files.
Task |
Description |
For Instructions |
---|---|---|
Use UNIX permissions to protect files |
Views UNIX permissions on files. Protects files with UNIX permissions. | |
Use ACLs to protect files |
Adds ACLs to protect files at a more granular level than UNIX permissions can. | |
Protect system from files that pose a security risk |
Finds executable files that have suspicious ownership. Disables files that can damage the system. |
The following task map points to procedures that list file permissions, change file permissions, and protect files with special file permissions.
Task |
For Instructions |
---|---|
Display file information | |
Change file ownership | |
Change file permissions |
How to Change File Permissions in Symbolic Mode |
Display information about all the files in a directory by using the ls command.
Type the following command to display a long listing of all files in the current directory.
% ls -la |
Displays the long format that includes user ownership, group ownership, and file permissions.
Displays all files, including hidden files that begin with a dot (.).
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.
The file owner, the Primary Administrator role, or superuser can change any file's ownership.
Display the permissions on a file.
% ls -l example-file -rw-r--r-- 1 janedoe staff 112640 May 24 10:49 example-file |
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.
Change the owner of the file.
# chown stacey example-file |
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 |
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.
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.
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.
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.
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.
Change permissions in symbolic mode.
% chmod who operator permissions filename |
Specifies whose permissions are to be changed.
Specifies the operation to be performed.
Specifies what permissions are to be changed. For the list of valid symbols, see Table 6–5.
Specifies the file or directory.
Verify that the permissions of the file have changed.
% ls -l filename |
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 |
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.
Change permissions in absolute mode.
% chmod nnn filename |
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.
Specifies the file or directory.
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.
Verify that the permissions of the file have changed.
% ls -l filename |
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 |
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.
Change special permissions in absolute mode.
% chmod nnnn filename |
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.
Specifies the file or directory.
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.
Verify that the permissions of the file have changed.
% ls -l filename |
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 |
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.
Task |
For Instructions |
---|---|
Determine if a file has an ACL | |
Add an ACL to a file | |
Copy an ACL | |
Modify an ACL | |
Remove ACLs from a file | |
Display the ACLs on a file |
% 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.
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.
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 |
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 ... |
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.
Specifies the file owner permissions.
Specifies the group ownership permissions.
Specifies the permissions for users other than the file owner or members of the group.
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.
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.
Specifies one or more files or directories on which to set the ACL. Multiple filenames are separated by spaces.
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.
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.
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:--- |
Copy a file's ACL to another file by redirecting the getfacl output.
% getfacl filename1 | setfacl -f - filename2 |
Specifies the file from which to copy the ACL.
Specifies the file on which to set the copied ACL.
In the following example, the ACL on ch2.sgm is copied to ch3.sgm.
% getfacl ch2.sgm | setfacl -f - ch3.sgm |
Modify ACL entries on a file by using the setfacl command.
% setfacl -m acl-entry-list filename ... |
Modifies the existing ACL entry.
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.
Specifies one or more files or directories, separated by a space.
Verify that the ACL entries were modified on the file.
% getfacl filename |
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 |
Delete ACL entries from a file.
% setfacl -d acl-entry-list filename ... |
Deletes the specified ACL entries.
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.
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.
Verify that the ACL entries were deleted from the file.
% getfacl filename |
In the following example, the user anusha is deleted from the ch4.sgm file.
% setfacl -d user:anusha ch4.sgm |
Display ACL entries for a file by using the getfacl command.
% getfacl [-a | -d] filename ... |
Displays the file name, file owner, file group, and ACL entries for the specified file or directory.
Displays the file name, file owner, file group, and the default ACL entries, if they exist, for the specified directory.
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.
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:--- |
The following task map points to procedures that find risky executables on the system, and that prevent programs from exploiting an executable stack.
Task |
Description |
For Instructions |
---|---|---|
Find files with special permissions |
Locates files with the setuid bit set, but that are not owned by the root user. | |
Prevent executable stack from overflowing |
Prevents programs from exploiting an executable stack. | |
Prevent logging of executable stack messages |
Turns off logging of executable stack messages. |
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.
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.
Find files with setuid permissions by using the find command.
# find directory -user root -perm -4000 -exec ls -ldb {} \; >/tmp/filename |
Checks all mounted paths starting at the specified directory, which can be root (/), sys, bin, or mail.
Displays files owned only by root.
Displays files only with permissions set to 4000.
Displays the output of the find command in ls -ldb format.
Is the file that contains the results of the find command.
Display the results in /tmp/filename.
# more /tmp/filename |
For background information on setuid permissions, see setuid Permission.
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 |
For a description of the security risks of executable stacks, see Preventing Executable Files From Compromising Security.
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.
Edit the /etc/system file, and add the following line:
set noexec_user_stack=1 |
Reboot the system.
# init 6 |
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 |