Guidelines for Running a Secure System

Guidelines for Handling Setuid and Setgid Programs

Since they pose great security liability to your system, note which programs are setuid and setgid and

Stay vigilant of any changes to them.
Investigate further any programs that appear to be needlessly setuid.
Change the permission of any unnecessarily setuid program to setgid.

The long form of the ls command (ll or ls -l) shows setuid programs by listing S or s instead of - or x for the owner-execute permission. It shows setgid programs by listing S or s instead of - or x for the group-execute permission.

You can expect to find setuid and setgid system files, but they should have the same permissions as provided by the factory media, unless you have customized them.

Users normally should not have setuid programs, especially setuid to users other than themselves.

Examine the code of all programs imported from external sources for destructive programs known as “Trojan Horses.” Never restore a setuid program for which you have no source to examine.

To allow users access to certain superuser programs, we recommend that you use Restricted SAM. Restricted SAM allows nonsuperusers to access particular areas of SAM. The area of SAM allowed is defined in /etc/sam/custom/login-name.cf for a user, where login-name is the user’s login name. See sam(1M) for details.

Why Setuid and Setgid Programs Can Be Risky

Whenever any program is executed, it creates a process with four ID numbers — real and effective user ID (ruid and euid) and real and effective group ID (rgid and egid). Typically, these ID pairs are identical.

However, running a setuid or setgid program changes the euid or egid of the process from that associated with the owner to that of the object. The processes spawned acquire their attributes from the object, giving the user the same access rights as the program’s owner and/or group.

If the setuid bit is turned on, the privileges of the process are set to that of the owner of the file.
If the setgid bit is turned on, the privileges of the process are set to that of the group of the file.
If neither the setuid nor setgid bit is turned on, the privileges of the process are unchanged.
As a particularly risky case, if a program is setuid to root, the user gains all privileges available to root. This is dangerous because the program can be used in a way that violates system security. To a lesser extent, this problem exists in other setuid and setgid cases as well.

How IDs are Set

The ruid and rgid are inherited from the login process, which sets your uid and gid. The specified uid and gid values are specified in /etc/passwd.
On a Trusted System, the aid (audit ID) stays unchanged upon login and is specified in the protected password database /tcb/files/auth/. The aid does not change when you run setuid and setgid programs. This improves accountability for actions.
The login command also changes the ruid, euid, rgid, and egid.
The su command changes the euid and ruid.
The newgrp command can change the gid.
Setuid and setgid bits are set by using the chmod() system call or chmod command. See chmod(1) and chmod(2).

A system attacker can exploit setuid and setgid programs, most often in one of two ways:

By having a setuid or setgid program execute commands defined by the attacker, either interactively or by script.
By substituting bogus data for the data created by a program.

Guidelines for Limiting Setuid Power

Use great caution if you add setuid-to-root programs to an existing system. Adding a setuid-to-root program changes the system configuration, and might compromise your security.

Enforce restrictive use of privileged programs through the following suggestions:

Use setuid and setgid only when absolutely necessary.
Make sure that no setuid program is writable by others.
Whenever possible, use setgid instead of setuid to reduce the scope of damage that might result from coding flaws or breaches of security.
Periodically search your file systems for new or modified setuid and setgid programs. You can use the ncheck -s command.
Know exactly what your setuid and setgid programs do, and verify that they do only what is intended. Failing this, remove the program or its setuid attribute.
If you must copy a setuid program, make sure that the modes are correct on the destination file.
Write setuid programs so that they can be tested on noncritical data, without setuid or setgid attributes. Apply these attributes only after the code has been reviewed and all affected departments are satisfied that the new programs maintain security.
Make sure that a setuid program does not create files writable by anyone other than its intended user.
Reset the euid before an exec(*) system call. Be aware that exec(*) may be called within other library routines, and be wary of using routines (including popen(), system(), execlp(), and execvp()) that fork a shell to execute a program. See exec(2), popen(3S), and system(3S).
When writing setuid programs, use setresuid() around the pieces of code that require privileges, to reduce the window of vulnerability. See setresuid(2).
Close all unnecessary file descriptors before calling exec(*).
Ensure that all variables (PATH, IFS) and the umask value in the program’s environment are sufficiently restrictive.
Do not use the creat() system call to make a lock file. Use lockf() or fcntl() instead. See lockf(2) and fcntl(2).
Be especially careful to avoid buffer overruns, such as through the use of sprintf(), strcpy(), and strcat() without proper parameter length validation. See printf(3S) and string(3C).

Guidelines for System Initialization

Most HP-supplied setuid-to-root programs begin by setting up a safe operating environment by establishing the following conditions:

Limiting environment variables to only those necessary for proper program operation.
Since Trojan Horses typically attack improperly set PATH and IFS variables, these are set to predetermined values. PATH is set to /usr/bin. IFS is set to space, tab, newline. All other environment variables are deleted. See environ(5).
All file descriptors other than standard input, standard output and standard error are closed. See close(2).
All alarms are turned off. All interval timers are set to zero. See getitimer(2).

These safeguards increase assurance that known programs are executed in a known environment.

Guidelines for Trusted Backup and Recovery

Use only fbackup and frecover to back up and recover files selectively. Only fbackup and frecover retain access control lists (ACLs). Use the -A option of these commands when backing up and recovering files for use on systems that do not implement ACLs. See fbackup(1M) and frecover(1M).
If you plan to recover the files to another system, be sure that the user’s user name and group name on both systems are consistent.
Remember that your backup media is sensitive material. Allow access to the media only on the basis of proven need.
Label backup tapes and store them securely. Offsite storage provides maximum security. Keep archives for a minimum of six months, then recycle the media.
Daily incremental and full weekly backups are recommended.
Synchronize your backup schedule with the information flow in your organization. For example, if a major database is updated every Friday, you might want to schedule your weekly backup on Friday evenings.
If all files must be backed up on schedule, request that all users log off before performing the backup. However, fbackup warns you if a file is changing while the backup is being performed.
Examine the log file of latest backups to identify problems occurring during backup. The backup log file should have restrictive permissions set.
frecover allows you to overwrite a file. However, the file retains the permissions and ACLs set when the file was backed up.
You must test your recovery process beforehand to make sure you can fully recover data in the event of an emergency.
When recovering files from another machine, you might have to execute the chown command to set the user ID and group ID for the system on which they now reside, if the user and group do not exist on the new system. If files are recovered to a new system that does not have the specified group, the files will take on the group ownership of the person running frecover. If owner and group names have different meanings on different systems, recovery results might be unexpected.
Power failure should not cause file loss. However, if someone reports a lost file after a power failure, look for it in /lost+found before restoring it from a backup tape.
To verify contents of the tape being recovered, use the -I option of frecover to preview the index of files on the tape. Note, however, that existing permissions of a file system are kept intact by the backup; frecover prevents you from reading the file if the permissions on the file forbid it.
Never recover in place any critical files such as /etc/passwd, or those in /tcb/files. Instead, restore the file to a temporary directory (do not use /tmp) and give this directory permissions drwx------, preventing anyone else from using it. Compare the restored files with those to be replaced. Make any necessary changes.
Auditing is not enabled automatically when you have recovered the system. Be sure to turn auditing on.

Guidelines for Mounting and Unmounting a File System

The mount command enables you to attach removable file systems and disk or disk partitions to an existing file tree. The mount command uses a file called /etc/fstab, which contains a list of available file systems and their corresponding mount positions. The /etc/fstab file should be writable only by root, but readable by others. Refer to “Managing File Systems” for more information on mounting file systems.

Observe the following precautions when mounting a file system or disk:

Create a mount point directory (such as /mnt) on which to mount a new file system. Never mount a file system in a directory that already contains files, because those files will become inaccessible.
The mount point of a mounted file system acquires the permissions and ownership of the file system’s root directory.
Use base mode permissions and access control list entries on disk path names to control access to disks.
Use the -r option of the mount command to mount the file system as read-only. Physically write-protected file systems must be mounted this way.
When mounting a new or foreign file system, assume that the medium is insecure.
- Create a directory restricted to root, by setting its permissions at 700 (drwx------).
  # mkdir /securefile # chmod 700 /securefile
- Run the fsck program to verify that the file system is not technically corrupted.
- Make sure that your PATH environment variable does not include “.” (the current directory); otherwise, you might run a Trojan Horse version of ls or some similar command while examining the new file system.
- Mount the foreign file system read-only at that location, for example, by loading the disk and typing:
  # mount /dev/disk1 /securefile -r
- Check all directories for special objects and privileged programs, and verify the identity of every program.
- Run ncheck -s to scan for setuid and setgid programs and device files, and investigate any suspicious findings.
- Remount the system read-write and remove any unnecessary setuid and setgid permissions from files that you discovered in the previous step. These precautions are especially important if a user requests that you mount a personal file system.
Only after performing these tests should you unmount the file system and remount it in its desired location.
Be sure to unmount all mounted file systems of a user whose account you are disabling or removing.

For information on files mounted in an NFS environment, see “Controlling Security on a Network”.

Guidelines for Handling Security Breaches

A security breach can present itself in many different ways:

Someone might report unexpected or destructive behavior by a common program.
You might notice a sudden increase in your system’s load average, causing the computer not to respond well.
Read/write permissions or ownership might be changed from what you expect.
The byte count of a system file changes unexpectedly.

Anything that seems to deviate from normal system behavior might suggest tampering. If you suspect a security breach, such as a virus or worm, handle it by limiting its immediate impact.

Shut down the system.
Bring the system up in a single-user state, its barest minimum. This limits the impact subject to symptoms. From a single-user state, analyze the problem and clean it up.
Mount all file systems, using mount -a.
Until their integrity has been verified, set restrictive directory permissions (drwx------) to prevent users from accessing the questionable files. This is a short-term solution only.
Compare file size from the previously backed-up system to the current one. Examine the dates that files were last written, check sums, byte count, inodes, and ownership. Suspect any files whose sizes differ unexpectedly. Remember, however, that some system files, especially network files, might have been customized, and therefore differ from the default system software.
Copy contaminated files to tape to save as evidence.
Under some circumstances, you might not be able to reboot, or you might not trust the reboot program (/sbin/init) itself. If so, you must reinstall your system.
If you are uncertain of the scope of damage, we recommend that you reinstall HP-UX from the distribution source media. You might also need to reinstall other software applications on your system.
After reinstalling, you must decide if you have corrupted any user files, or other files not reinstalled from tape.
Mount users’ home directories and run the find and ncheck commands to uncover any additional compromised files.
If the breach was an unauthorized access of your machine, under most circumstances, the point of entry will be apparent. Disable those accounts, replacing the password entries with an asterisk. The root user then has to change the password by hand.
In any case, it is recommended that you check all accounts on the system.
Inform all system users of a security breach and ask them to check their accounts for anything unusual. Instruct users to run ls -lt to look for unexpected changes to files, such as time of last modification for file creation or mode change, which might suggest tampering.
Analyze evidence to determine how the breach occurred and what can be done to prevent recurrences.

Tracking Root

A useful method to keep track of system access and reduce security breaches on standard and trusted servers is to physically secure the system console and allow root to login only at the system console. Users logging in through other ports must first log in as themselves, then execute su to become root.

To limit root to logging in only through the system console, create the /etc/securetty file with the single entry, console, as follows:

# echo console > /etc/securetty

This restriction applies to all login names that have user ID 0 (superuser). See login(1) for more details.