Movatterモバイル変換


[0]ホーム

URL:


Go to main content
oracle home

Developer's Guide to Oracle® Solaris 11.4 Security

Exit Print View

 
Search Scope:
  »  ...Documentation Home  »  Oracle Solaris 11.4 Information Library  »  Developer's Guide to Oracle® ...  »  Developing Privileged Applications  »  About Privileges
Updated: November 2020
 
 

About Privileges

A privilege is a discrete right that is granted to a process to perform an operation that would otherwise be prohibited by the Oracle Solaris OS. Most programs do not require extra privilege, because a program typically operates within the bounds of the system security policy.

Privileges are assigned by an administrator. Those privileges can be used to satisfy the privilege requirements of the program. At login or when a profile shell is entered, the user's privileges apply to any commands that are run in the shell. When an application is run, privileges can be turned on or turned off by the program. If a new program is started by using theexec(1) command, that program can potentially use all of the parent process's inheritable privileges. However, that program cannot add any new privileges.

How Administrators Assign Privileges

System administrators are responsible for assigning privileges to commands. For more information about privilege assignment, seeMore About Privileges inSecuring Users and Processes in Oracle Solaris 11.4.

How Privileges Are Implemented

    Every process has four sets of privileges that determine whether a process can use a particular privilege:

  • Permitted privilege set

  • Inheritable privilege set

  • Limit privilege set

  • Effective privilege set

Permitted Privilege Set

All privileges that a process can ever potentially use must be included in the permitted set. Conversely, any privilege that is never to be used should be excluded from the permitted set for that program.

When a process is started, that process inherits the permitted privilegeset from the parent process. Typically at login or from a new profile shell,all privileges are included in the initial set of permitted privileges. Theprivileges in this set are specified by the administrator. Each child processcan remove privileges from the permitted set, but the child cannot add otherprivileges to the permitted set. As a security precaution, you should removethose privileges from the permitted set that the program never uses. In thisway, a program can be protected from using an incorrectly assigned or inheritedprivilege.

Privileges that are removed from the permitted set are automaticallyremoved from the effective set.

Inheritable Privilege Set

At login or from a new profile shell, the inheritable set contains the privileges that have been specified by the administrator. These inheritable privileges can potentially be passed on to child processes after anexec(1) call. A process should remove any unnecessary privileges to prevent these privileges from passing on to a child process. Often the permitted and inheritable sets are the same. However, there can be cases where a privilege is taken out of the inheritable set, but that privilege remains in the permitted set.

Limit Privilege Set

The limit set enables a developer to control which privileges a process can exercise or pass on to child processes. A child process and the descendant processes can only obtain privileges that are in the limit set. When asetuid(0) function is run, the limit set determines the privileges that the application is permitted to use. The limit set is enforced atexec(1) time. Removal of privileges from the limit set does not affect any other sets until theexec (1) is performed.

Effective Privilege Set

The privileges that a process can actually use are in the process's effective set. At the start of a program, the effective set is equal to the permitted set. Afterwards, the effective set is either a subset of or is equal to the permitted set.

A good practice is to reduce the effective set to the set of basic privileges.The basic privilege set, which contains the core privileges, is describedinPrivilege Categories. Remove completelyany privileges that are not needed in the program. Toggle off any basic privilegesuntil that privilege is needed. For example, thefile_dac_read privilege,enables all files to be read. A program can have multiple routines for readingfiles. The program turns off all privileges initially and turns onfile_dac_read, for appropriate reading routines. The developer thus ensures thatthe program cannot exercise thefile_dac_read privilegefor the wrong reading routines. This practice is calledprivilegebracketing. Privilege bracketing is demonstrated inPrivilege Coding Example.

Compatibility Between the Superuser and Privilege Models

To accommodate legacy applications, the implementation of privileges works with both the superuser and privilege models. This accommodation is achieved through use of thePRIV_AWARE flag, which indicates that a program works with privileges. A process inheritsPRIV_AWARE on afork(2) orexec(2) from its parent.

Consider a child process that is not aware of privileges. ThePRIV_AWARE flag for that process would be false. Any privileges that have been inherited from the parent process are available in the permitted and effective sets. If the child sets a UID to 0, the process's effective and permitted sets are restricted to those privileges in the limit set. The child process does not gain full superuser powers. Thus, the limit set of a privilege-aware process restricts the superuser privileges of any non-privilege-aware child processes. If the child process modifies any privilege set, then thePRIV_AWARE flag is set to true.

Privilege Categories

    Privileges are logically grouped on the basis of the scope of the privilege, as follows:

  • Basic privileges – The basic privileges are privileges granted to all processes, including user processes, by default. However, programs and administrators can remove a basic privilege to further restrict a process.

    • PRIV_DAX_ACCESS – Allows a process to perform all operations supported by the DAX hardware.

    • PRIV_FILE_LINK_ANY – Allows a process to create hard links to files that are owned by a UID other than the process's effective UID.

    • PRIV_FILE_READ – Allows a process to read objects in the file system.

    • PRIV_FILE_WRITE – Allows a process to modify objects in the file system.

    • PRIV_NET_ACCESS – Allows a process to open a TCP, UDP, SDP, or SCTP network endpoint.

    • PRIV_PROC_EXEC – Allows a process to callexecve().

    • PRIV_PROC_FORK – Allows a process to callfork(),fork1(), orvfork().

    • PRIV_PROC_INFO – Allows a process to examine the status of processes outside of those processes to which the inquiring process can send signals. Without this privilege, processes that cannot be seen in/proc cannot be examined.

    • PRIV_PROC_SELF – Allows a process to access files under/proc, including/proc/self.

    • PRIV_PROC_SESSION – Allows a process to send signals or trace processes outside its session.

    • PRIV_SYS_IB_INFO – Allows a process to perform read InfiniBand MAD (Management Datagram) operations.

    Initially, the basic privilegesshould be assigned as a set rather than individually for a program. This approachensures that any basic privileges that are released in an update to the Oracle Solaris OS will be included in the assignment. However, when computing theneeded privilege set for a program, it is important to remove basic privilegesthat are not needed and add other privileges that will be needed by the program.For example, theproc_exec privilege should be turned offif the program is not intended toexec(1) subprocesses.

    All privileges are named by category, the word following "PRIV_" in the privilege name. Current categories include the following:

    • CMI
    • CONTRACT
    • CPC
    • DTRACE
    • FILE
    • GRAPHICS
    • IPC
    • KSTAT
    • NET
    • PROC
    • SYS
    • VIRT

See theprivileges(7) man page for a complete list of the Oracle Solaris privileges with descriptions.


Note -  The Oracle Solaris Zones feature enables an administrator to configure isolated environments for applications. See thezones(7) man page,Creating and Using Oracle Solaris Zones andResource Management and Oracle Solaris Zones Developer’s Guide for more information. Because a process in a zone cannot monitor or interfere with other activity in the system outside of that zone, any privileges on that process are limited to the zone as well. However, if needed, thePRIV_PROC_ZONE privilege can be applied to processes in the global zone that need privileges to operate in non-global zones.
Copyright © 2000, 2020, Oracle and/or its affiliates. 
Previous
Next

[8]ページ先頭

©2009-2025 Movatter.jp