SUID/SGID of UNIX files

From: http://fanqiang.chinaunix.net/a1/b5/20010808/1000001088.html

I. SUID/SGID Overview

Sometimes, an unauthorized user needs to complete a task. One example is the passwd program, which allows the user to change the password, which requires changing the password domain of the/etc/passwd file. However, the system administrator never allows common users to directly change the file, because this is definitely not a good idea.
To solve this problem, SUID/SGID came into being. UNIX allows the program to be authorized. When the program is executed, it has the permissions of the super user, and then returns to the permissions of the common user. This idea is good, so at&t applied for a patent for it.

II. Introduction to some terms in UNIX

1. File Permission. Determine the user's right to read, modify, or execute files.
R -- Read access
W -- Write Access
X -- execute the license
S -- SUID/SGID
T -- Sticky Bit
2. process. A process is a process that runs once to complete a scheduled task. It is different from a program. Each process has a unique process ID. In addition, each process has other identifiers: actual user ID, actual group ID, valid user ID, and valid group ID. The actual user ID and valid user ID of the superuser process are 0.
3. Super User Root. Super Users have full control over the system.

Iii. SUID/SGID ideas

During running, the SUID program changes the valid user ID to the owner ID of the program, so that the process has the privileges of the owner of the program. If it is set to SUID root, the process will have the privileges of Super Users (of course, some newer UNIX systems have enhanced security detection in this aspect, to a certain extent, it reduces security risks ). When the process ends, it returns to the original state.

Note: The real uid of the SUID/SGID program during execution can be changed through the setuid () function.

4. a suid Program

The following program is used to demonstrate the SUID of a UNIX file, named parent. c

# Include <stdio. h> 〉
# Include <stdlib. h> 〉
# Include <unistd. h> 〉
# Include <sys/types. h> 〉
Int
Main (INT argc, char ** argv)
{
Int I;
Char ** argu;
Uid_t uid;
Uid = geteuid (); // get the valid user ID of the calling Process
If (argc <2 ){
Fprintf (stderr, "Usage: % s /N ", argv [0]);
Exit (0 );
}
If (setuid (UID) <0 ){
Fputs ("setuid error./N", stderr );
Exit (1 );
} // Set the actual user ID of the calling process to a valid user ID
If (argu = (char **) malloc (argc * sizeof (char *) = NULL ){
Fputs ("malloc error./N", stderr );
Exit (1 );
} // Allocate memory space for the parameter pointer array of execvp
For (I = 0; I

This program converts a SUID process into a superuser process. Compile the program into the executable target file parent and use another simple program for verification.

Int main (void ){
Printf ("Real uid = % d, valid tive uid = % d/N", getuid (), geteuid ());
Exit (0 );
}

Compiled as printuids. Run the program to get the following results:

$./Parent printuids // normal execution, no privilege
Real uid = 506, valid tive uid = 506
$ Su Root
Password:
# Chown root parent // change the owner
# Chmod U + S parent // Add SUID
# Exit
$./Parent printuidsv real uid = 0, valid tive uid = 0 // This process is transformed into a superuser Process

Once a process is transformed into a superuser process, it will have full control of the system. For example, we can execute the demo program: $./parent useradd hacker
$./Parent passwd hacker
Therefore, SUID programs are often accompanied by certain security issues. In the early Unix environment, the SUID/SGID program calls the system () function and there is a security vulnerability.

V. Discuss the security issues of the SUID/SGID program.

Sometimes, the interaction between a SUID program and a system program (or library function) will generate a security vulnerability that is unknown to the programmer of the program. A typical example is the/usr/lib/preserve program. It is used by VI and ex editors. When a user is accidentally interrupted by the system before writing a change to the file, it can automatically create a copy of the file being edited. This saved (preserve) program will write changes to a temporary file in a dedicated directory, then, use the/bin/mail program to send the user a notification that "the file has been saved.
Because people may be editing a private or confidential file, the directory used by the preserve Program (old version) cannot be accessed by general users. To enable the preserve program to write to that directory and enable the recover program to read from there, these programs are set to SUID root. This preserve program has three features worth noting:
1. This program is set to SUID root.
2. Run the/bin/mail program as the root user.
3. This program calls the system () function to call the mail program.
Because the system () function calls shell to perform syntax analysis on the command string, shell uses the IFS Variable as the delimiter of the input field. In earlier versions of shell, this variable is not restored to a common character set when called. If you first set IFS to "/", then call the VI Program, and then call the preserve program, it is possible that the usr/lib/preserve program will execute a bin program in the current directory (/bin/mail will be parsed as a bin program with the mail parameter ).
If we use the preceding demo program to compile a simple shell script file named "bin", it may be executed through the preceding security vulnerability:

# Shell script to make an SUID-Root
Shell
#
Chown root parent
Chmod 4755 parent

Then the consequence is ......

　 References:
W. Richard Steven S: Advanced Programming in the Unix environment
Simson garfinkel, Gene spafford: pracitical UNIX & Internet Security