dtrace discuss - Oct 2008 - dtrace_kernel and privilege escalation

hey..

I talked to my sysadmins about getting access to the dtrace_kernel role, and
they said they were hesitant to give this out because they thought it was a
security risk - ie: that you could use it for privilege escalation.

How true is this? Is there a way to make it user safe? If not, why is it offered
as an option for regular users?

Thanks much,

Ed
--
This message posted from opensolaris.org

hey..

I talked to my sysadmins about getting access to the dtrace_kernel role, and
they said they were hesitant to give this out because they thought it was a
security risk - ie: that you could use it for privilege escalation by getting
passwords,etc.

How true is this? Is there a way to make it user safe? If not, why is it offered
as an option for regular users?

Thanks much,

Ed
--
This message posted from opensolaris.org

On Tue, Oct 14, 2008 at 10:19:35AM -0700, Edward Peschko
wrote:
> hey..
> 
> I talked to my sysadmins about getting access to the dtrace_kernel role,
and they said they were hesitant to give this out because they thought it was a
security risk - ie: that you could use it for privilege escalation.
Yes, they''re absolutely right.  Take a machine on which you do have
dtrace_kernel, and run Brendan''s diabolical shellsnoop:

  http://www.brendangregg.com/DTrace/shellsnoop
> How true is this? Is there a way to make it user safe? If not, why is it
offered as an option for regular users?
That should answer your last question. ;)

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems Fishworks.       http://blogs.sun.com/bmc

On Tue, Oct 14, 2008 at 10:19:35AM -0700, Edward Peschko wrote:
...

Bryan answered the rest of your questions. I''ll take a swing at:
> If not, why is it offered as an option for regular users?
dtrace_kernel is provided as a separate privilege for the same reason
as many of the other privileges that confer large amounts of power:  because
it allows flexibility and minimizing risk.

On my work desktop, which I have complete control over, I give myself all of the
dtrace privileges.  That allows me to do quick tests of dtrace stuff, and
destructive actions which effect process I own, without allowing me to panic
the system.  For those kinds of things, I have to su(1M) to root.

Perhaps the description in privileges(5) should be updated to note the implied
access to all kernel state.

Cheers,
- jonathan

>> If not, why is it offered as an option for regular users?
> dtrace_kernel is provided as a separate privilege for the same reason
> as many of the other privileges that confer large amounts of power: because
> it allows flexibility and minimizing risk.
ok.. I understand the intent, but that doesn''t really help in many
situations. I, too, can have my own setup at home (and give myself what I want)
but I can''t set up the whole development environment that I''m
working on offsite, limiting the troubleshooting usefulness of dtrace.

I guess I''m looking for a way to look into the kernel state without
necessarily being able to look into *all* kernel state - ie: selectively  for
all processes that I control.

I don''t know how feasible something like this would be, but it would be
extremely useful for lots of larger development environments.

Ed
--
This message posted from opensolaris.org

On Wed, Oct 15, 2008 at 11:37:13AM -0700, Edward Peschko
wrote:
> ok.. I understand the intent, but that doesn''t really help in many
> situations. I, too, can have my own setup at home (and give myself
> what I want) but I can''t set up the whole development environment
that
> I''m working on offsite, limiting the troubleshooting usefulness of
> dtrace.
In such situations the thing to do is to work with a sysadmin who will
review and run your scripts on your behalf.

It''s what we do.  When posters on cifs-discuss at opensolaris.org, say,
need help and we need more information we often send them DTrace scripts
to run, and they send us back the output (check the archives).  We
don''t
ask for privileged (or any) access to customers'' systems!  Yet we
manage
to get the data that we need.
> I guess I''m looking for a way to look into the kernel state
without
> necessarily being able to look into *all* kernel state - ie:
> selectively  for all processes that I control.
> 
> I don''t know how feasible something like this would be, but it
would
> be extremely useful for lots of larger development environments.
I can imagine things that could be done to create a crippled
dtrace_kernel, but it would be very difficult to convince anyone that
those things are enough to prevent privilege escalation.  And the result
would likely be too constrained for your purposes anyways.  Which means
there''d be no upside to putting any effort into such a project.

Nico
--