Guidelines for using trusted facilities

Follow these guidelines when you use trusted facilities:

• Consult your security administrator before running programs that write sensitive system files, need super-user privilege, or manipulate kernel data structures.

• Be careful to use appropriate environment variables and data files. Set up a program's environment and signal handling dispositions to ensure that a user cannot make the program do something unintended; the program should catch SIGINT, SIGQUIT, and so on. This is essential for programs that execute other programs using the exec(S), system(S), and popen(S) commands. SUID programs should always set up the IFS, PATH, and SHELL environment variables.

• Use a restricted umask, such as 077, for programs that create private files.

• Use full (absolute) pathnames when executing program files from the shell.

• Protect programs from general readership.

• Setuid programs that run other programs are vulnerable; some can be penetrated easily. When passing control to a sub-program, use setuid(S) and setgid(S) to restore the original permissions. Make sure that all files needed by only the parent process are closed before invoking the child program. In general, use these privileges for the shortest amount of time possible. For example, if you need privilege to open a file, use:

     main
     	get enhanced priv
     	open file
     	drop enhanced priv
     	write file
     	...
  

• Recall that the access(S) system call and the eaccess(S) system call are different. Use the appropriate one.

  In most cases, use eaccess(S), which checks against effective UID and GID. Use access(S), which checks against the real UID and GID, when you are running a setuid(S) or setgid(S) binary.

• Catch and handle all expected signals. It is important to undo any partially done actions that might leave sensitive files in an inconsistent state.
  

• Leave things in a sensible state, in all error cases. Ensure that relevant exception conditions are handled appropriately.

• Handle concurrency. If two users are likely to run a program concurrently, make sure that any files to be modified are locked during the modification.

• Handle errors in file and user input formats. It is possible for any file to be corrupted, and errors that cause your program to fail or leave files or permissions in an inconsistent state invite penetrators. To make sure your system security is not compromised, check your return codes, and investigate and fix errors or inconsistencies. Be particularly conscious of overflowing buffers when reading input, which can cause unpredictable and potentially harmful behavior.