Managing Systems and Workgroups: A Guide for HP-UX System Administrators

Administering a System: Managing System Security
Guidelines for Running a Secure System
Chapter 8 775
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.