dtrace discuss - Jul 2011 - tick probes for unprivileged users

All,

A(nother) longstanding DTrace annoyance has been that tick probes,
while enableable by users with limited privilege, will only fire if
the context matches one that the user is allowed to instrument.
Specifically:  if a user uses tick probes from within a zone, they
will only fire if that zone happens to be running on the CPU on which
the tick probe fires.  This breaks many scripts that (naturally) use
tick probes as a kind of local timeout mechanism.  For us at Joyent,
this has become a top annoyance for our customers who themselves want
to use DTrace from within the zone, so we wanted to take a swing at
addressing this -- but we also needed to be mindful (obviously) of not
allowing privilege escalation.  Complicating things, I also wanted to
do this in a way that preserves the existing behavior for the profile
probes:  that they don''t fire when in a context that one cannot
execute is actually the easiest way of assuring that a profile-based
enabling in the non-global zone does (roughly) what the user thinks it
does.  So the model we came to is to split the behavior (slightly) of
the profile provider, and use the provider''s dtps_usermode (which I
have renamed to dtps_mode) to inform as to both mode (kernel mode v.
user mode) and policy (if the user cannot execute in this context,
this firing should be dropped v. restricted).  When restricted, the
user does not have either proc privileges, nor the privileges
necessary to examine arguments, and attempts to do so will induce a
UPRIV or KPRIV fault (respectively).  From the (new) block comment
explaining the dtps_mode entry point, the return value from dpts_mode
is:

   A bitwise OR that encapsulates both the mode (either DTRACE_MODE_KERNEL
   or DTRACE_MODE_USER) and the policy when the privilege of the enabling
   is insufficient for that mode (either DTRACE_MODE_NOPRIV_DROP or
   DTRACE_MODE_NOPRIV_RESTRICT).  If the policy is DTRACE_MODE_NOPRIV_DROP,
   insufficient privilege will result in the probe firing being silently
   ignored for the enabling; if the policy is DTRACE_NODE_NOPRIV_RESTRICT,
   insufficient privilege will not prevent probe processing for the
   enabling, but restrictions will be in place that induce a UPRIV fault
   upon attempt to examine probe arguments or current process state.

Attached is a patch that implements this.  I have integrated this into
our bits at Joyent (internal ticket is OS-431, "dtrace profile and
tick probes sometimes don''t fire in a zone"), so -- as with our
other
work -- you''ll see this show up soon (next two weeks or so) at
http://github.com/joyent/illumos-joyent, but I wanted to give folks an
earlier heads-up in case we want to have further discussion here.  In
particular:  Adam, it would be great if you could take a look at this
at some point -- though I would obviously welcome anyone else''s
feedback as well!

        - Bryan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtrace-tick.patch
Type: application/octet-stream
Size: 24981 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20110709/bc7f9739/attachment-0001.obj>

Hey Bryan,

This not only adds great value, but also makes the code better. Just a
couple of nits:

dtrace_prive_probe()
I think the comment belongs before the previous if block (i.e. before
we calldtps_mode())

The ASSERT: where''s logical xor when you need it?!

"Currently, the only times we''ll this check .." -- missing a
verb

dtrace.h
The overview for dtps_mode() could be better; how about this:
  Called to determine the execute mode of the fired probe and the appropriate
  policy for an unprivileged firing.
Writing that, I realized that the mode is dynamic while the policy of what to
do in an unprivileged case is static and could be part of provider
registration -- but whatever.

Adam

On Sat, Jul 9, 2011 at 1:42 PM, Bryan Cantrill <bryan at joyent.com>
wrote:
> All,
>
> A(nother) longstanding DTrace annoyance has been that tick probes,
> while enableable by users with limited privilege, will only fire if
> the context matches one that the user is allowed to instrument.
> Specifically: ?if a user uses tick probes from within a zone, they
> will only fire if that zone happens to be running on the CPU on which
> the tick probe fires. ?This breaks many scripts that (naturally) use
> tick probes as a kind of local timeout mechanism. ?For us at Joyent,
> this has become a top annoyance for our customers who themselves want
> to use DTrace from within the zone, so we wanted to take a swing at
> addressing this -- but we also needed to be mindful (obviously) of not
> allowing privilege escalation. ?Complicating things, I also wanted to
> do this in a way that preserves the existing behavior for the profile
> probes: ?that they don''t fire when in a context that one cannot
> execute is actually the easiest way of assuring that a profile-based
> enabling in the non-global zone does (roughly) what the user thinks it
> does. ?So the model we came to is to split the behavior (slightly) of
> the profile provider, and use the provider''s dtps_usermode (which
I
> have renamed to dtps_mode) to inform as to both mode (kernel mode v.
> user mode) and policy (if the user cannot execute in this context,
> this firing should be dropped v. restricted). ?When restricted, the
> user does not have either proc privileges, nor the privileges
> necessary to examine arguments, and attempts to do so will induce a
> UPRIV or KPRIV fault (respectively). ?From the (new) block comment
> explaining the dtps_mode entry point, the return value from dpts_mode
> is:
>
> ? A bitwise OR that encapsulates both the mode (either DTRACE_MODE_KERNEL
> ? or DTRACE_MODE_USER) and the policy when the privilege of the enabling
> ? is insufficient for that mode (either DTRACE_MODE_NOPRIV_DROP or
> ? DTRACE_MODE_NOPRIV_RESTRICT). ?If the policy is DTRACE_MODE_NOPRIV_DROP,
> ? insufficient privilege will result in the probe firing being silently
> ? ignored for the enabling; if the policy is DTRACE_NODE_NOPRIV_RESTRICT,
> ? insufficient privilege will not prevent probe processing for the
> ? enabling, but restrictions will be in place that induce a UPRIV fault
> ? upon attempt to examine probe arguments or current process state.
>
> Attached is a patch that implements this. ?I have integrated this into
> our bits at Joyent (internal ticket is OS-431, "dtrace profile and
> tick probes sometimes don''t fire in a zone"), so -- as with
our other
> work -- you''ll see this show up soon (next two weeks or so) at
> http://github.com/joyent/illumos-joyent, but I wanted to give folks an
> earlier heads-up in case we want to have further discussion here. ?In
> particular: ?Adam, it would be great if you could take a look at this
> at some point -- though I would obviously welcome anyone else''s
> feedback as well!
>
> ? ? ? ?- Bryan
>
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer
>
>


-- 
Adam Leventhal, Delphix
http://dtrace.org/blogs/ahl

275 Middlefield Road, Suite 50
Menlo Park, CA 94025
http://www.delphix.com