Chapter 35 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.

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:

user-name::::defaultpriv=basic,privilege

To give a running process an additional privilege, use the ppriv(1) command:

# ppriv -s A+privilege process-ID

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.

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), and may use the following actions and variables:

dtrace_proc Privilege

The dtrace_proc privilege permits use of the fasttrap provider for process-level tracing. It also allows the use of the following actions and variables:

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.

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.

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.

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:

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 and Chapter 19, profile Provider for a discussion of the performance impact of the syscall and profile providers.

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.

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.