 |
» |
|
|
|
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
