Hello everyone. We are actively diving into work and already preparing many powerful launches for January. Among other things, we have announced recruitment for a new stream of the beloved course. Ahead of the launch, we traditionally share a translation of useful material.
File permissions offer a safe alternative to SUID executables, but they may seem a bit confusing at first glance.
We all know that binary files include Fortunately, if your application requires certain limited privileges, there is a more effective method called .
I'll save you time if you want to avoid reading the detailed article above: essentially, file permissions allow processes running under the root user, which therefore have the right to do anything, to retain certain capabilities limited to , when they drop privileges and run as an unprivileged user. This means that if an attacker manages to compromise a process through a buffer overflow or another exploit, they will only be able to use the specific minimal privileges that the process genuinely needs.
Permissions work great for services that typically always run as the root user, but what about command-line utilities? Fortunately, this is also supported, provided you have the right utilities installed. If you're using Ubuntu, for instance, you'll need the package libcap2-bin.You will also need to run a non-archaic kernel (starting from version 2.6.24).
). These features allow you to associate permissions with executables similarly to configuring the SUID bit, but only for a specific set of permissions. The utility setcap is used to add and remove permissions from a file.
The first step is to choose the permissions you need. For this article, I assume there is a network diagnostic tool called tracewalk,which should be able to use Usually, this requires the application to run as the root user, but upon examination , it turns out that only the permission CAP_NET_RAW is needed..
Assuming you are in the directory where the binary file is located tracewalk,, you can add this capability as follows:
sudo setcap cap_net_raw=eip tracewalk For now, ignore the suffix =eip for the capability; I will explain this in a moment. Note that the capability name is in lowercase. You can now check if you set the permissions correctly with:
setcap -v cap_new_raw=eip tracewalkOr you can list all capabilities set for the given executable file:
getcap tracewalk
For your information, you can also remove all capabilities from the executable file with:
setcap -r tracewalkAt this stage, you should be able to run the executable as an unprivileged user, and it should be able to work with raw sockets, but without any other privileges that the root user has.
So, what does this strange suffix mean? =eip? Здесь потребуется толика понимания природы разрешений. Каждый процесс имеет три набора разрешений — effective, inheritable, and permitted (effective, inheritable, and permitted):
- Effective capabilities are those that determine what the process can actually do. For example, it cannot deal with raw sockets if
CAP_NET_RAW is needed.it is not in the effective set. - Permitted capabilities are those that the process is allowed to have if it requests them with the appropriate call. They do not allow the process to actually do anything unless it has been specifically written to request the specified capability. This allows processes to gain particularly important permissions in the effective set only for the period when they are truly needed.
- Inheritable capabilities are those that can be inherited in the permitted set of a spawned child process. During the operation
fork()orclone()the child process is always given a copy of the parent process’s capabilities, as at this moment it is still executing the same executable file. The inheritable set is used whenexec()(or similar) is called to replace the executable file with another. At this stage, the process's permitted set is masked by the inheritable set to get the available set that will be used for the new process.
Thus, the utility setcap allows us to add the permissions of these three sets independently for a given executable file. Note that the value of groups is interpreted somewhat differently for file access rights:
- Available file permissions are those that are always available for the executable file, even if the parent process that called it did not have them. They were previously known as 'forced' permissions.
- Inherited file permissions define an additional mask that can also be used to remove permissions from the calling process's set. They are applied in addition to the inherited set of the calling process, so permission is inherited only if it exists in both sets.
- Effective file permissions actually represent just one bit, not a set, and if it is set, then the entire available set is also copied into the effective set of the new process. This can be used to add permissions to processes that were not specifically written to request them. Since this is one bit, if you set it for any permission, it must be set for all permissions. You might think of it as a legacy bit because it is used to allow the use of permissions for applications that do not support them.
When specifying permissions via setcap three letters e, i and p correspond to effective, inherited, and permitted sets respectively. So, the earlier specification:
sudo setcap cap_net_raw=eip tracewalk … indicates that the permission CAP_NET_RAW is needed. must be added to the permitted and inherited sets and that the effective bit must also be set. This will replace any previously set permissions in the file. To set multiple permissions at once, use a list separated by commas:
sudo setcap cap_net_admin,cap_net_raw=eip tracewalkdiscusses all this in more detail, but hopefully, this post has demystified some of what is happening. It only remains to mention a few caveats and tricks.
First of all, file capabilities do not work with symlinks — you have to apply them to the binary file itself (that is, to the target of the symlink).
Secondly, they do not work with interpreted scripts. For example, if you have a Python script to which you want to assign permissions, you must assign it to the Python interpreter itself. Clearly, this presents a potential security issue because all scripts executed with this interpreter will have the specified permissions, although it is still significantly better than making it SUID. The most common workaround apparently involves writing a separate executable file in C or an equivalent that can perform the necessary operations and calling it from the script. This is similar to the approach used by Wireshark, which utilizes a binary file /usr/bin/dumpcap to perform privileged operations:
$ getcap /usr/bin/dumpcap
/usr/bin/dumpcap = cap_net_admin,cap_net_raw+eip Thirdly, file permissions are disabled if you use an environment variable LD_LIBRARY_PATH for obvious security reasons(1). The same applies to LD_PRELOAD, as far as I know.
1. Since an attacker can evidently substitute one of the standard libraries and use LD_LIBRARY_PATH, to cause their library to be called in preference to the system one, and thus have their arbitrary code executed with the same privileges as the calling application.
That's all. More details about the course program will be available at the
Source: habr.com
