There is a domain transition situation where, through a chain of domain transitions, the domain is returned to its original domain. This interesting situation is a typical case of the transition chain so that we have an outline of how the SELinux system works. Thereby we also see much work to be done to develop security policies.
The domain transition circle executing the rpm package manager program
When we run the rpm command to install an rpm package as the root user, the current domain is sysadm_t. The domain is then transitioned to rpm_t to execute the rpm program. As for the internal technical aspect of the SELinux-enabled kernel, the target of the domain transition is not a new domain but the type of execution program. That means the type of the execution program determines which domain is the resultant domain to be transitioned to. For the kernel, the new domain is only the result of the domain transition computation.
The type of the rpm program file is rpm_exec_t
Therefore, the domain is transitioned to rpm_t because of the statement
rpm_run(sysadm_t, sysadm_r)
in the sysadm policy module that has been installed.
Right now rpm is running in the rpm_t domain. Until it executes the package installation script, ie, runs a shell of type shell_exec_t, the domain is transitioned to rpm_script_t by the statement
rpm_domtrans_script(rpm_t)
is present in the rpm policy module that has been installed.
The rpm_script_t domain used to run the script is granted quite a lot of appropriate permissions, but because the installation script is so varied, sometimes rpm_script_t is not sufficient to execute. This is the case when the script needs to run generic programs (the program files do not have a private SELinux type, using a generic type of bin_t) that rpm_script_t does not have permission required by the program. Meanwhile the sysadm_t domain obviously has this capability equipped in the sysadm policy module. So we transition the domain back to sysadm_t to meet the program's requirements
domtrans_pattern(rpm_script_t, bin_t, sysadm_t)
So the domain has returned to its origin, sysadm_t. It is the image of a domain transition circle.
Security specialization for the rpm package manager program
If we do not want to go back to sysadm_t to run bin_t programs, we can grant permission additionally to the rpm_script_t domain to let it execute itself. A discovery was found that when the sed command is encountered, the sed program calls the setfscreatecon() function to set the security context used to create a new file. This requires rpm_script_t to have setfscreate permission. In addition, it is required to map non-authentication files into memory (most files in the system belong to the non_auth_file_type group, except for a few special files such as shadow_t that are not in this group)
allow rpm_script_t self:process setfscreate; files_map_non_auth_files(rpm_script_t)
Now rpm_script_t is able to run the package installation script without resorting to sysadm_t. But there is another issue to consider: in the sysadm policy module the following two statements already existed by default
rpm_admin(sysadm_t, sysadm_r) files_manage_non_auth_files(sysadm_t)
That makes sysadm_t able to run the rpm program without needing to transition the domain to rpm_t. So if rpm_t is to be the only specialized domain that can run rpm, we need to remove the above two statements from the sysadm module. Particularly, the files_manage_non_auth_files(sysadm_t) statement makes sysadm_t arbitrary manipulation of the rpm package manager data files because they are all in the non_auth_file_type group. However, the files_manage_non_auth_files interface needs to be replaced with a set of detailed rules that only removes the management permission for rpm program data files.
If the rpm program has been specialized, which means that root can no longer run rpm without transitioning the domain to rpm_t, there is one problem to solve: similar to useradd, when running the rpm command with sudo, the domain will not transition to rpm_t but stop at sysadm_t and cannot execute the command. As such, the last thing to do is to patch the sudo package similarly as we did with the shadow package.
Contact: tuyen@omarine.org
Comments
There are currently no comments
New Comment