{anchor:top}
h1. {anchor:CHP-SEC} Security
This chapter describes the privileges that system administrators can use to grant access to DTrace to particular users or processes. DTrace enables visibility into all aspects of the system including user-level functions, system calls, kernel functions, and more. It allows for powerful actions some of which can modify a program's state. Just as it would be inappropriate to allow a user access to another user's private files, a system administrator should not grant every user full access to all the facilities that DTrace offers. By default, only the super-user can use DTrace. The Least Privilege facility can be used to allow other users controlled use of DTrace.
[Top|#top]
h2. {anchor:CHP-SEC-1} Privileges
The Solaris Least Privilege facility enables administrators to grant specific privileges to specific Solaris users. To give a user a privilege on login, insert a line into the {{/etc/user_attr}} file of the form:
{noformat}
user-name::::defaultpriv=basic,privilege
{noformat}
To give a running process an additional privilege, use the [{{ppriv}}(1)|http://docs.sun.com/doc/819-2239/ppriv-1?a=view] command:
{noformat}
# ppriv -s A+privilege process-ID
{noformat}
The three privileges that control a user's access to DTrace features are {{dtrace_proc}}, {{dtrace_user}}, and {{dtrace_kernel}}. Each privilege permits the use of a certain set of DTrace providers, actions, and variables, and each corresponds to a particular type of use of DTrace. The privilege modes are described in detail in the following sections. System administrators should carefully weigh each user's need against the visibility and performance impact of the different privilege modes. Users need at least one of the three DTrace privileges in order to use any of the DTrace functionality.
[Top|#top]
h2. {anchor:CHP-SEC-2} Privileged Use of DTrace
Users with any of the three DTrace privileges may enable probes provided by the {{dtrace}} provider (see [Chapter 17, dtrace Provider|dtrace Provider]), and may use the following actions and variables:
|Providers|{{dtrace}}| | |
|Actions|{{exit}}|{{printf}}|{{tracemem}}|
| |{{discard}}|{{speculate}}| |
| |{{printa}}|{{trace}}| |
|Variables|{{args}}|{{probemod}}|{{this}}|
| |{{epid}}|{{probename}}|{{timestamp}}|
| |{{id}}|{{probeprov}}|{{vtimestamp}}|
| |{{probefunc}}|{{self}}| |
|Address Spaces|None| | |
[Top|#top]
h2. {anchor:CHP-SEC-PROC} {{dtrace_proc}} Privilege
The {{dtrace_proc}} privilege permits use of the {{pid}} and {{fasttrap}} providers for process-level tracing. It also allows the use of the following actions and variables:
|Providers|{{pid}}| | |
|Actions|{{copyin}}|{{copyout}}|{{stop}}|
| |{{copyinstr}}|{{raise}}|{{ustack}}|
|Variables|{{execname}}|{{pid}}|{{uregs}}|
|Address Spaces|User| | |
This privilege does not grant any visibility to Solaris kernel data structures or to processes for which the user does not have permission.\\
\\Users with this privilege may create and enable probes in processes that they own. If the user also has the {{proc_owner}} privilege, probes may be created and enabled in any process. The {{dtrace_proc}} privilege is intended for users interested in the debugging or performance analysis of user processes. This privilege is ideal for a developer working on a new application or an engineer trying to improve an application's performance in a production environment.
{info:title=Note}
Users with the {{dtrace_proc}} and {{proc_owner}} privileges may _enable_ any {{pid}} probe from any process, but can only create probes in processes whose privilege set is a subset of their own privilege set. Refer to the Least Privilege documentation for complete details.
{info}
The {{dtrace_proc}} privilege allows access to DTrace that can impose a performance penalty only on those processes to which the user has permission. The instrumented processes will impose more of a load on the system resources, and as such it may have some small impact on the overall system performance. Aside from this increase in overall load, this privilege does not allow any instrumentation that impacts performance for any processes other than those being traced. As this privilege grants users no additional visibility into other processes or the kernel itself, it is recommended that this privilege be granted to all users that may need to better understand the inner-workings of their own processes.
[Top|#top]
h2. {anchor:CHP-SEC-USER} {{dtrace_user}} Privilege
The {{dtrace_user}} privilege permits use of the {{profile}} and {{syscall}} providers with some caveats, and the use of the following actions and variables:
|Providers|{{profile}}|{{syscall}}|{{fasttrap}}|
|Actions|{{copyin}}|{{copyout}}|{{stop}}|
| |{{copyinstr}}|{{raise}}|{{ustack}}|
|Variables|{{execname}}|{{pid}}|{{uregs}}|
|Address Spaces|User| | |
The {{dtrace_user}} privilege provides only visibility to those processes to which the user already has permission; it does not allow any visibility into kernel state or activity. With this privilege, users may enable the {{syscall}} provider, but the enabled probes will only activate in processes to which the user has permission. Similarly, the {{profile}} provider may be enabled, but the enabled probes will only activate in processes to which the user has permission, never in the Solaris kernel.\\
\\This privilege permits the use of instrumentation that, while only allowing visibility into particular processes, can affect overall system performance. The {{syscall}} provider has some small performance impact on every system call for every process. The {{profile}} provider affects overall system performance by executing every time interval, similar to a real-time timer. Neither of these performance degradations is so great as to severely limit the system's progress, but system administrators should consider the implications of granting a user this privilege. Refer to [Chapter 21, syscall Provider|syscall Provider] and [Chapter 19, profile Provider|profile Provider] for a discussion of the performance impact of the {{syscall}} and {{profile}} providers.
[Top|#top]
h2. {anchor:CHP-SEC-5} {{dtrace_kernel}} Privilege
The {{dtrace_kernel}} privilege permits the use of every provider except for the use of the {{pid}} and {{fasttrap}} providers on processes not owned by the user. This privilege also permits the use of all actions and variables except for kernel destructive actions ({{breakpoint}}, {{panic}}, {{chill}}). This privilege permits complete visibility into kernel and user state. The facilities enabled by the {{dtrace_user}} privilege are a strict subset of those enabled by {{dtrace_kernel}}.
|Providers|All with above restrictions| |
|Actions|All but destructive actions| |
|Variables|All| |
|Address Spaces|User|Kernel|
[Top|#top]
h2. {anchor:CHP-SEC-6} Super User Privileges
A user with all privileges may use every provider and every action including the kernel destructive actions unavailable to every other class of user.
|Providers|All| |
|Actions|All including destructive actions| |
|Variables|All| |
|Address Spaces|User|Kernel|
{excerpt:hidden=true}Converted by tech dogg's sgml2wiki on Tue 20 Nov 2007 at 9:27:41 PM{excerpt}
h1. {anchor:CHP-SEC} Security
This chapter describes the privileges that system administrators can use to grant access to DTrace to particular users or processes. DTrace enables visibility into all aspects of the system including user-level functions, system calls, kernel functions, and more. It allows for powerful actions some of which can modify a program's state. Just as it would be inappropriate to allow a user access to another user's private files, a system administrator should not grant every user full access to all the facilities that DTrace offers. By default, only the super-user can use DTrace. The Least Privilege facility can be used to allow other users controlled use of DTrace.
[Top|#top]
h2. {anchor:CHP-SEC-1} Privileges
The Solaris Least Privilege facility enables administrators to grant specific privileges to specific Solaris users. To give a user a privilege on login, insert a line into the {{/etc/user_attr}} file of the form:
{noformat}
user-name::::defaultpriv=basic,privilege
{noformat}
To give a running process an additional privilege, use the [{{ppriv}}(1)|http://docs.sun.com/doc/819-2239/ppriv-1?a=view] command:
{noformat}
# ppriv -s A+privilege process-ID
{noformat}
The three privileges that control a user's access to DTrace features are {{dtrace_proc}}, {{dtrace_user}}, and {{dtrace_kernel}}. Each privilege permits the use of a certain set of DTrace providers, actions, and variables, and each corresponds to a particular type of use of DTrace. The privilege modes are described in detail in the following sections. System administrators should carefully weigh each user's need against the visibility and performance impact of the different privilege modes. Users need at least one of the three DTrace privileges in order to use any of the DTrace functionality.
[Top|#top]
h2. {anchor:CHP-SEC-2} Privileged Use of DTrace
Users with any of the three DTrace privileges may enable probes provided by the {{dtrace}} provider (see [Chapter 17, dtrace Provider|dtrace Provider]), and may use the following actions and variables:
|Providers|{{dtrace}}| | |
|Actions|{{exit}}|{{printf}}|{{tracemem}}|
| |{{discard}}|{{speculate}}| |
| |{{printa}}|{{trace}}| |
|Variables|{{args}}|{{probemod}}|{{this}}|
| |{{epid}}|{{probename}}|{{timestamp}}|
| |{{id}}|{{probeprov}}|{{vtimestamp}}|
| |{{probefunc}}|{{self}}| |
|Address Spaces|None| | |
[Top|#top]
h2. {anchor:CHP-SEC-PROC} {{dtrace_proc}} Privilege
The {{dtrace_proc}} privilege permits use of the {{pid}} and {{fasttrap}} providers for process-level tracing. It also allows the use of the following actions and variables:
|Providers|{{pid}}| | |
|Actions|{{copyin}}|{{copyout}}|{{stop}}|
| |{{copyinstr}}|{{raise}}|{{ustack}}|
|Variables|{{execname}}|{{pid}}|{{uregs}}|
|Address Spaces|User| | |
This privilege does not grant any visibility to Solaris kernel data structures or to processes for which the user does not have permission.\\
\\Users with this privilege may create and enable probes in processes that they own. If the user also has the {{proc_owner}} privilege, probes may be created and enabled in any process. The {{dtrace_proc}} privilege is intended for users interested in the debugging or performance analysis of user processes. This privilege is ideal for a developer working on a new application or an engineer trying to improve an application's performance in a production environment.
{info:title=Note}
Users with the {{dtrace_proc}} and {{proc_owner}} privileges may _enable_ any {{pid}} probe from any process, but can only create probes in processes whose privilege set is a subset of their own privilege set. Refer to the Least Privilege documentation for complete details.
{info}
The {{dtrace_proc}} privilege allows access to DTrace that can impose a performance penalty only on those processes to which the user has permission. The instrumented processes will impose more of a load on the system resources, and as such it may have some small impact on the overall system performance. Aside from this increase in overall load, this privilege does not allow any instrumentation that impacts performance for any processes other than those being traced. As this privilege grants users no additional visibility into other processes or the kernel itself, it is recommended that this privilege be granted to all users that may need to better understand the inner-workings of their own processes.
[Top|#top]
h2. {anchor:CHP-SEC-USER} {{dtrace_user}} Privilege
The {{dtrace_user}} privilege permits use of the {{profile}} and {{syscall}} providers with some caveats, and the use of the following actions and variables:
|Providers|{{profile}}|{{syscall}}|{{fasttrap}}|
|Actions|{{copyin}}|{{copyout}}|{{stop}}|
| |{{copyinstr}}|{{raise}}|{{ustack}}|
|Variables|{{execname}}|{{pid}}|{{uregs}}|
|Address Spaces|User| | |
The {{dtrace_user}} privilege provides only visibility to those processes to which the user already has permission; it does not allow any visibility into kernel state or activity. With this privilege, users may enable the {{syscall}} provider, but the enabled probes will only activate in processes to which the user has permission. Similarly, the {{profile}} provider may be enabled, but the enabled probes will only activate in processes to which the user has permission, never in the Solaris kernel.\\
\\This privilege permits the use of instrumentation that, while only allowing visibility into particular processes, can affect overall system performance. The {{syscall}} provider has some small performance impact on every system call for every process. The {{profile}} provider affects overall system performance by executing every time interval, similar to a real-time timer. Neither of these performance degradations is so great as to severely limit the system's progress, but system administrators should consider the implications of granting a user this privilege. Refer to [Chapter 21, syscall Provider|syscall Provider] and [Chapter 19, profile Provider|profile Provider] for a discussion of the performance impact of the {{syscall}} and {{profile}} providers.
[Top|#top]
h2. {anchor:CHP-SEC-5} {{dtrace_kernel}} Privilege
The {{dtrace_kernel}} privilege permits the use of every provider except for the use of the {{pid}} and {{fasttrap}} providers on processes not owned by the user. This privilege also permits the use of all actions and variables except for kernel destructive actions ({{breakpoint}}, {{panic}}, {{chill}}). This privilege permits complete visibility into kernel and user state. The facilities enabled by the {{dtrace_user}} privilege are a strict subset of those enabled by {{dtrace_kernel}}.
|Providers|All with above restrictions| |
|Actions|All but destructive actions| |
|Variables|All| |
|Address Spaces|User|Kernel|
[Top|#top]
h2. {anchor:CHP-SEC-6} Super User Privileges
A user with all privileges may use every provider and every action including the kernel destructive actions unavailable to every other class of user.
|Providers|All| |
|Actions|All including destructive actions| |
|Variables|All| |
|Address Spaces|User|Kernel|
{excerpt:hidden=true}Converted by tech dogg's sgml2wiki on Tue 20 Nov 2007 at 9:27:41 PM{excerpt}