13.1 (Conspect) Policy and security
The topic is what to do on the system if we want to perform an action that is not available to the average user.
Steps:
- The most important method to allow this to a user with other rights is to write a SUID wripper. This is a program that would use the SUID technology. Let's make the utility check the context of the launches for any features it considers necessary. Let's write this logic to the program in the language the utility is written in and everything will work. For example, let's see the su utility. This utility can be launched only by 'wheel' members.
- Get rid of SUID programs, in favor of SGID. The idea is to distribute access rights in this way, so that an entire group of resources can have access to some group. And, as a rule, an ordinary user cannot be a member of this group. And this group is necessary exactly for a utility running with the rights of our user SGID - that is, with a change in the group identifier, suddenly gain access to this resource. For example, iputils. This is better than SUID because SUID is root, i.e. all possible rights. SGID is a simple change of group indicator, no additional rights SGID process does not get. This effect is associated with the technology SUID - directory traversal.
Group shadow - in which no one is a member, but there may be SUID programs that get the rights of group shadow. So it is not root, but it wants to access some other file. The program that works with the file must be SGID and shadow (for example, passwd). When we run passwd from a user, userI D of that program is saved, the ID group turns into a shadow. And with this permission, it can go through all directories.
Why is it called directory traversal? Because we're in a normal state, we can't get from this directory (to the user directory), because it's locked with the directory /tcb/ . And until we run an SGID process that can go through /tcb/ to use shadow, we won't get there.
- Writing a special utility with which we will explain in a special language what we can and cannot run. Utility sudo. It is arranged in this way. It has the right to configure itself to run only the user of the 'wheel' group. Sudo - allows you to launch a user/group/user categories/ some action with the rights of another user. This is a very unreliable authorization mechanism. It has disadvantages:
- Very frozen language of command design. It is rather complicated, inept editing can give out rights to the one you do not want. Nobody takes care of its code to the end.
- It's not flexible.
Polkit
Read manual Polkit with interpreting pictures: Polkit manual
Polkit is an ip for programs that allows the user to know 1) whether the user has the right to perform this request 2) to perform this request. The role is distributed as follows: There is an authentication agent that asks if the user can do something or not. Polkit looks at the policy file where the rules for giving out permissions for individual actions to users/processes are described. It finds the right ones, checks them and if allowed, pulls the corresponding mechanism and executes the right action if at some point it is 'prohibited' to do so. And then nothing can be done.
Rules: javascript program Policy: config file program