Dear Experts, My customer is migrating to Solaris 10 from Solaris 8 and have asked me to determine if: With Dtrace, is the user limited to probing only processes they own? The customer has a general security requirement to control user access via management of privileges. Currently, on Solaris 8, LDAP is strongly while RBAC is weakly applied. This will likely change in the Solaris 10 production environment. Thanks, Evans ------- Evans C. Harrigan X52669 SWAN Principal Engineer 949-225-9669 Voice Client Services 949-833-8330 FAX Sun Fed SE Org. West 949-300-9956 Cell Sun Microsystems, Inc.
Evans Harrigan wrote:> Dear Experts, > > My customer is migrating to Solaris 10 from Solaris 8 and have asked me to determine if: With Dtrace, is the user limited to probing only processes they own?this depends entirely on the privileges you grant a user. By default, non-root users don''t have any dtrace_* privileges at all. HTH Michael -- Michael Schuster Recursion, n.: see ''Recursion''
Thanks, Michael. This will please the customer immensely. Evans ------- Evans C. Harrigan X52669 SWAN Principal Engineer 949-225-9669 Voice Client Services 949-833-8330 FAX Sun Fed SE Org. West 949-300-9956 Cell Sun Microsystems, Inc. ----- Original Message ----- From: Michael Schuster <Michael.Schuster at Sun.COM> Date: Friday, April 27, 2007 2:48 pm Subject: Re: [dtrace-discuss] User Privileges and Dtrace To: Evans Harrigan <Evans.Harrigan at Sun.COM> Cc: dtrace-discuss at opensolaris.org> Evans Harrigan wrote: > > Dear Experts, > > > > My customer is migrating to Solaris 10 from Solaris 8 and have > asked me to determine if: With Dtrace, is the user limited to > probing only processes they own? > > this depends entirely on the privileges you grant a user. By > default, > non-root users don''t have any dtrace_* privileges at all. > > HTH > Michael > -- > Michael Schuster > Recursion, n.: see ''Recursion'' > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >
On Fri, Apr 27, 2007 at 02:47:44PM -0700, Michael Schuster wrote:> >My customer is migrating to Solaris 10 from Solaris 8 and have asked me to > >determine if: With Dtrace, is the user limited to probing only processes > >they own? > > this depends entirely on the privileges you grant a user. By default, > non-root users don''t have any dtrace_* privileges at all.As detailed in the Solaris Dynamic Tracing Guide, you can give ordinary users the dtrace_proc and dtrace_user privileges which only allow them to view activity in processes that they own. For more detail, take a look at the docs: http://docs.sun.com/app/docs/doc/817-6223/6mlkidln0?a=view Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Since dtrace_proc and dtrace_user as far as I know are rather comparable to access to truss or sotruss (except of course that dtrace can give far more information about the same processes, and be far more flexible), I''m curious why they weren''t made "basic" privileges. It''s not as if anyone can''t (within whatever resource controls allow) find simpler ways of soaking up resources, and given the limitations on those two, I don''t see that there is much other potential for abuse; but maybe I''m not being imaginative enough. :-) Of the dtrace privileges, if I understand correctly, only dtrace_kernel gives users a view of activity that may have nothing to do with their processes, right? I don''t suppose there''s a way to readily distinguish between kernel activity that can be attributed to a process owned by the user, and activity that can''t, such that dtrace_kernel could be split in two, so that one could allow (even if this shouldn''t be "basic") a user to see kernel processing that could be attributed to processes they owned, without seeing anything else; and another privilege that allowed the rest of what dtrace_kernel allows now. I think that might allow some additional choices to be made balancing use and security. Of course, even actively tracing certain types of activity by one''s own processes would have more performance impact than not tracing them, so one might not wish to hand it out willy-nilly; but if the main concern were unauthorized access to information, the distinction might be useful if it were to prove reasonably feasible. -- This message posted from opensolaris.org
Ok, I read a bit further; I agree that at least one of those two privs might have performance impacts that might not be constrained by resource controls and might not be able to be caused any other way. But I''m not so sure that applies to the other of those privs, in which case I still don''t see why it shouldn''t be "basic". -- This message posted from opensolaris.org
As you noticed, the dtrace_user privilege can induce a performance hit for all processes. The dtrace_proc privilege was left out the set of basic privileges because we were being conservative. DTrace consumers can allocate a bunch of kernel memory and cause kernel activity with interrupts disabled; these aren''t so scary, but we didn''t want to allow DTrace use by default in case there was some security problem. After 3 years in the wild, it seems like it might be time to consider adding dtrace_proc to the set of basic privs as was our eventual goal. Adam On Wed, May 02, 2007 at 11:33:56PM -0700, Richard L. Hamilton wrote:> Ok, I read a bit further; I agree that at least one of those two privs might > have performance impacts that might not be constrained by resource controls > and might not be able to be caused any other way. But I''m not so sure that > applies to the other of those privs, in which case I still don''t see why it > shouldn''t be "basic". > -- > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl