Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
HP-UX System Administrator's Guide: Security Management: HP-UX 11i Version 3 > Chapter 2 Administering User and System Security

Handling setuid and setgid Programs


Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

Because they pose a potential security risk to the system, note which programs are setuid (set user ID) and setgid (set group ID) programs. 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.

Follow these guidelines to secure setuid and setgid programs:

  • Watch for any changes to setuid and setgid programs.

  • Investigate further any programs that appear to be unnecessary setuid programs.

  • Change the permission of a program that is unnecessarily a setuid program to a setgid program. See chmod(1) and chmod(2) for more information.

    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.

  • Do not allow users to normally have setuid programs, especially when they use 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 or install a setuid program for which you have no source to examine.

  • To allow users access to certain superuser programs, HP recommends that you use Restricted SMH. Restricted SMH allows non-superusers to access particular areas of SMH. See smh(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 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 the 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.

For security reasons, the setuid and setgid bits on scripts are normally ignored by the HP-UX kernel. This rule can be relaxed by changing the tunable secure_sid_scripts, but it is strongly recommended that this tunable be not changed from the default. For more information on this tunable, see secure_sid_scripts(5).

How IDs Are Set

IDs are set in these different ways:

  • The ruid and rgid are inherited from the login process, which sets your uid and gid. The uid and gid values are specified in /etc/passwd.

  • 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.

  • Set the setuid and setgid bits by using the chmod() system call or chmod command. See chmod(1) and chmod(2) for more information.

Guidelines for Limiting Setuid Power

Use 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 security.

Enforce restrictive use of privileged programs through the following administrative and programming recommendations:

  • 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 the file systems for new or modified setuid and setgid programs. You can use the ncheck -s command.

  • Know exactly what the 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(*) can 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) for more information.

  • When writing setuid programs, use setresuid() around the pieces of code that require privileges, to reduce the window of vulnerability. See setresuid(2) for more information.

  • 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) for more information.

  • Be especially careful to avoid buffer overruns, for example, by using sprintf(), strcpy(), and strcat() without proper parameter length validation. See printf(3S) and string(3C) for more information.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2008 Hewlett-Packard Development Company, L.P.