To understand how the current solutions for the delegation of system administration are structured, it is important to understand the way that UNIX was originally designed and specifically the methods that were offered in this original design to manage the delegation of admin tasks. Originally, there were just two different kinds of UNIX processes: privileged processes and unprivileged processes. An unprivileged process was limited in its way of performing system functions, where privileged processes were designed to bypass all restrictions. To execute privileged processes, the root user account was used: a user account with no limitations whatsoever. From the beginning, the concept of the root account was designed to perform system administration tasts without limitation whatsoever.
To help normal (unprivileged) users run administration tasks, several solutions were created. One of them was sudo. The purpose of sudo (short for superuser so) was simple: connect a user or a group of users to a privileged process of commands. Sudo allows normal users to run root tasks. Stated otherwise, sudo allows normal users to start a task that creates an environment in which these normal users are roo, and if for any reason there is a backdoor or bug in such a task, there is a risk that through that task, the user gets complete root access. However, before further zooming into sudo particularities, let us have a look at the supported mechanisms that are offered by the UNIX and Linux operating systems.
Since about the year 2000, when the first 2.2 Linux kernels were released, the feature of “capabilities” was introduced in the kernel with the purpose of offering more choice than just that between privileged and unprivileged processes. A capability determines rights to specific tasks, such as changing of ownership (CAP_CHOWN), changing of permissions (CAP_CHMOD), or the capability to terminate running tasks on a server (CAP_KILL). In total, there are about 32 capabilities, and the idea of using these was to define in a more granular way what exactly a process or thread is allowed to do.
And this works fine for system processes that are started with an unprivileged user account. However, it does not work that fine for a system task that was started by the root user, because if the real user ID that was used for executing a task is zero, all capabilities are enabled. Therefore, capabilities are a partially useful attempt to limit the way administration tasks are performed, but for a modern global enterprise, they are not enough.
Capabilities are a large step forward to a more secured environment, but their effectiveness is related to the user account that runs a task. That is why in current Linux it is not that easy to use capabilities for the delegation of system administration tasks. An example of a service that does use capabilities is AppArmor of SELinux. These security mechanisms, both based on the security framework in the Linux kernel, allow administrators to set-up profiles that limit the things that programs can do in the operating system. In that profile, the application is allowed to use certain capabilities and access certain files, while at the same time it blocks access to those that are not in the application profile. Although seen as an important step forward in offering better security for Linux, these solutions do not handle the particular needs that are required for the efficient delegation of system administration tasks.