Guidelines for Running a Trusted 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 instead of - or x for the owner-execute permission. It shows setgid programs by listing 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, it is recommended that Restricted SAM be used. Restricted SAM allows non-superusers 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.

Why setuid Programs Can Be Risky

Whenever any program is executed, it creates a process with four 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.
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 to violate system security.

How IDs are Set

The ruid and rgid are inherited from the login process, which sets your uid and gid. The uid and gid are located in /etc/passwd.
The aid (audit ID) stays unchanged upon login and is located in /tcb/files/auth/*/*. The aid does not change when running setuid and setgid programs.
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 command. Use chmod 4000 for the setuid bit, chmod 2000 for the setgid bit.

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, or
By substituting bogus data for the data created by a program.

Guidelines for Limiting setuid Power

You must not add setuid-to-root programs to an existing trusted 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 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.
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 non-critical 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.
When writing setuid programs, use setresuid(2) around the pieces of code that require privileges, to reduce the window of vulnerability.
Close all unnecessary file descriptors before calling exec().
Ensure that all variables (PATH, IFS, and umask) 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.

Guidelines for System Initialization

HP-UX sets up a safe operating environment at the start of most setuid-to-root programs by calling a special library function to establish the following conditions:

Environment variables are set to only those values necessary for the proper operation of setuid programs.
Since Trojan Horses typically attack improperly set PATH and IFS variables, these are set to predetermined values: PATH is set to /bin:/usr/bin. IFS is set to space, tab, and 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.

These library functions cannot be applied to some programs, because to do so would inhibit their specified behavior. Instead, you should carefully examine these programs for potential flaws:

Title not available (Guidelines for System Initialization )

at(1), crontab(1): Specified shell environment variables are retained when the commands are executed.
hpterm(1), xterm(1): Some file descriptors other than standard input, standard output, and standard error remain open.
newgrp(1): All exported variables retain their value.
su(1): The environment is passed along unchanged.

Guidelines for Trusted Backup and Recovery

Use only fbackup(1M) and frecover(1M) to back up and recover files selectively. Only fbackup(1M) and frecover(1M) 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.
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(1M) warns you if a file is changing while the backup is being performed.
Examine the logfile of latest backups to identify problems occurring during backup. The backup logfile should have restrictive permissions set.
frecover(1M) 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(1M). 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(1M) 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(1M) 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 /tmp directory, and give this directory permission 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 to an existing file tree removable file systems and disk or disk partitions. The mount command uses a file called /etc/fstab, which contains a list of available file systems and their permissions. The /etc/fstab file should be writable only by root, but readable by others. Refer to Chapter 4 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 the directory tree already containing 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). 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. Remove any unnecessary setuid and setgid permissions from files. These precautions are especially important if a user requests that you mount a personal file system.
- Run the fsck program to verify that the file system is not technically corrupted.
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" later in this chapter.

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 any system files 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.
You want to 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 date files were last written, 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 (/etc/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 system tapes. 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 at the console 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.

A useful method to keep track of system access and reduce security breach is to physically secure the system console and allow root login only at the system console. Users logging in through other ttys must first log in as themselves, then as su (root).