Example--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 Permissions in Absolute Mode
Use the following procedure to change special permissions in absolute mode.
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 the special permissions on a file or directory.
Change special permissions in absolute mode by using the chmod command.
$ chmod nnnn filename
nnnn
Specifies the octal values that change the permissions on the file or directory. The first octal value on the left sets the special permissions on the file. For the list of valid octal values for the special permissions, see Table 15-6.
filename
Specifies the file or directory.
Note - If 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
Examples--Setting Special 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 |
How to Change Permissions in Symbolic Mode
Use the following procedure to change permissions in symbolic mode.
If you are not the owner of the file or directory, become superuser.
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 by using the chmod command.
$ chmod who operator permission filename
who operator permission
who specifies whose permissions are to be changed, operator specifies the operation to be performed, and permission specifies what permissions are to be changed. For the list of valid symbols, see Table 15-7.
filename
Specifies the file or directory.
Verify that the permissions of the file have changed.
$ ls -l filename
Examples--Changing Permissions in Symbolic Mode
In the following example, read permission are taken away from others.
$ chmod o-r filea |
In the following example, read and execute permissions are added for user, group, and others.
$ chmod a+rx fileb |
In the following example, read, write, and execute permissions are assigned to group.
$ chmod g=rwx filec |
Searching for Special Permissions
You should monitor your system for any unauthorized use of the setuid and setgid permissions on programs to gain superuser privileges. A suspicious listing grants ownership of such a program to a user rather than to root or bin.
How to Find Files With setuid Permissions
Use the following procedure to find files with setuid permissions.
Find files with setuid permissions by using the find command.
# find directory -user root -perm -4000 -exec ls -ldb {} \; >/tmp/filenamefind 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
Writes results to this file.
Display the results in /tmp/filename.
# more /tmp/filename
If you need background information about setuid permissions, see "setuid Permission".
Example--Finding Files With setuid Permissions
# find / -user root -perm -4000 -exec ls -ldb {} \; > /tmp/ckprm
# cat /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
|
This output 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, rar can execute /usr/rar/bin/sh and become the privileged user. If you want to save this output for future reference, move the file out of the /tmp directory.
Executable Stacks and 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 (available starting in the Solaris 2.6 release) enables you to specify whether stack mappings are executable. By default, the variable is set to zero, except on 64-bit applications, which provides ABI-compliant behavior. If the variable is set to non-zero, 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, which 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 to the /var/adm/messages file. For more information, see the syslogd(1M) and syslog.conf(4) man pages.
This message is useful for observing potential security problems, as well as to identify valid programs that depend upon executable stacks that have been prevented from correct operation by setting this variable. If the administrator does not want any messages logged, then the noexec_user_stack_log variable can be set to zero to disable it in the /etc/system file, though the SIGSEGV signal can continue to cause the executing program to core dump.
You can use mprotect 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 only available on sun4m and sun4u platforms.