6.2.2. Access rights of processes to Unix-Linux resources

As already noted, the rights of the processes depend on the rights of the user who launched the process. In the Unix family of operating systems, processes have four identifiers associated with access rights. These are user IDs RUID, EUID (real and effective) and group identifiers RGID, EGID . RUID and RGID are always set equal to the UID and GID of the user who started the process. By default, the EUID and EGID will also be equal to the UID and GID of the user who started the process. However, as noted above, if the file has the SUID or SGID bits set, then the EUID and EGID will be equal to the UID and GID of the owner-user and group-owner, respectively. An example is the passwd utility, which is owned by root , and has the SUID bit set. This gives the right to any user to change their password and save the changes in the password file. It is also worth noting that, in any case, the passwd utility can determine by RUID and EUID bits whether the superuser started it, or another user on behalf of the superuser. And accordingly, for ordinary users, it can provide only limited rights. For example, the superuser can change the password of any user without even knowing his old password. When child processes start, they inherit the permissions of the parent process. Therefore, it is necessary to set the SUID and SGID bits with great care and only for programs that do not have the ability to run arbitrary tasks, since, for example, a command interpreter running on behalf of the superuser provides almost unlimited possibilities.

As already noted, the superuser has unlimited rights. To work with a superuser, you can simply log in as root . However, this mode is not recommended because, firstly, when working as root, there are no records about what actions the superuser performed, and secondly, the script for registering the superuser does not imply collecting any other identifying information (for example, if root can include several people, it is impossible to determine who exactly logged on to the system) and, thirdly, any careless actions can lead to irreversible consequences. Therefore, to ensure greater security, registration as root is prohibited on terminals and over the network, i.e. everywhere except the system console.

In order for another user to perform operations as root , there are 2 options: the su command and the sudo utility. To use the su command, the user must log in with any arbitrary name and then call the su command with no parameters. In this case, the superuser password will be requested, and if the correct password is specified, a command interpreter will be launched with superuser rights. In many systems, the user must also be a member of a group with a GID = 0 . In general, the su command allows you to run the command interpreter on behalf of any user specified as a parameter. The su command is intended primarily for system administrators and not for regular users. In some cases, it may be necessary to allow some users to execute certain commands on behalf of the superuser. To do this, you can use the sudo utility. The sudo program takes as a parameter the command line that is to be executed with root user privileges . The file / usr / local / etc / sudoers contains a list of users and a list of commands that they have the right to execute on the specified machines. If all the permissions match, before executing the specified command, sudo prompts the user for his password and executes the specified command on behalf of the superuser. The sudo program keeps a log of the executed commands, the users that called them, and the time of the call. Only the superuser can edit the sudoers file using a special visudo utility. It must take great care when setting permissions in the sudoers file and must provide users with a minimum set of commands sufficient to perform the required operations.

Thus, we can conclude that the security subsystem of the OS of the Unix family is quite effective, and most Unix systems correspond in all respects to security class C2. However, it is worth noting that the system administrator must be very responsible in terms of security issues, since any incorrect action (for example, allowing users to access the password file, start the command interpreter with root privileges, and run unchecked or unreliable scripts and programs on behalf of superuser) can negate all the advantages of the Unix security system.