|
|
Having a privilege means having the ability to override access controls to perform a sensitive system operation. In previous releases of UnixWare, there was one privilege, commonly called root or superuser, which could override any restrictions and perform sensitive services. This meant that a user who was to perform a given privileged operation had to be given the power to perform any privileged operation. For example, an application on the system executed by ordinary users might need to exceed some system limit, such as the number of files held open by a single process. In this case, the application would have to be set to execute as root, using the set-UID mechanism, for users to execute it without running afoul of the system limits. But this meant that the application now had the ability to circumvent all system controls, including access controls. The security risks of such an all-powerful privilege are obvious and enormous.
For the system to be secure, the security policy requires that this single superuser privilege be subdivided into a set of privileges known collectively as process privileges. Privileges are no longer associated with user IDs, but with processes and executable files. In the example from the previous paragraph, you could now set a single privilege on the application, allowing it to exceed the system limits without bypassing other system restrictions. However, there are still cases where the ability to become an all-powerful user is still necessary. Therefore, the system still recognizes root as the all-powerful user, by associating all privileges with any process with a user ID of 0.
A process that accesses privileged components of the operating system will require the appropriate privilege. Thus, any process that runs with privileges is considered part of the operating system, because the privilege it has gives it the authority to perform some sensitive action. A misused privilege could compromise security. Thus, privileges and privileged processes must be carefully controlled.
The division of the ability to perform certain privileged tasks is necessary to enforce the principle of least privilege as required by the security policy. According to that principle, a process should never have more privileges than it needs at a given time.
Each executable file can have two sets of privileges associated with it; they are fixed and inheritable privileges. These sets are disjoint, that is, a privilege can not be defined as both fixed and inheritable for the same file. If an executable file does not require any privileges then both sets are empty. Inheritable privileges can be set, but have no effect. They are present for future work only.
Each running process can have two sets of privileges associated with it; they are maximum and working.
When a new process is created, using the fork(2) system call, the new process inherits the maximum and working sets of its parent.
Processes need a particular privilege to bypass a particular system restriction. A process executes an executable file using the exec(2) system call. When the process executes the file, any fixed privileges on the file are passed to the process. These are added to any privileges the process may already possess, and this result becomes the new maximum set and working set for the process.
Process privileges enhance the control the system exercises over the execution of sensitive actions, providing enhanced security.
The administrative command that manages process privileges on a file is
The system call that manages process privileges on a file is The user-level system calls for dealing with process privileges are For more information on process privileges and the principle of least privilege, see ``Privileges associated with a process''.