Hi, A customer would like to run DTrace on some production boxes however they need a way to prove that no destructive actions can be taken, not even by accident. This "proof" is required before they can do anything on the production boxes. Is there an executable or possibly an RBAC controllable action that can be done to strip the "-w" functionality from the DTrace executable? Or possibly strip some privileges that won''t allow DTrace to do anything destructive? Thanks, Brian
Brian Kolaci wrote:> Hi, > > A customer would like to run DTrace on some production boxes > however they need a way to prove that no destructive actions > can be taken, not even by accident. This "proof" is required > before they can do anything on the production boxes. > > Is there an executable or possibly an RBAC controllable > action that can be done to strip the "-w" functionality from > the DTrace executable? Or possibly strip some privileges that > won''t allow DTrace to do anything destructive? > > Thanks, > > Brian > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >According to the manual, if you give all of the dtrace privs to a normal user, that user can access everything except destructive actions, which is still reserved for the super user. As such a user a ran a script that did a "chip(10)", and got the following error: dtrace: error on enabled probe ID 3 (ID 13: syscall::read:return): invalid kernel access in action #2 Chip
Chip Bennett wrote:> > According to the manual, if you give all of the dtrace privs to a normal > user, that user can access everything except destructive actions, which > is still reserved for the super user. As such a user a ran a script > that did a "chip(10)", and got the following error: > > dtrace: error on enabled probe ID 3 (ID 13: syscall::read:return): > invalid kernel access in action #2 > >Pardon me, That should have been a "chill(10)". Sorry. Chip (not 10) ;-)
Chip Bennett wrote:> Chip Bennett wrote: >> >> According to the manual, if you give all of the dtrace privs to a >> normal user, that user can access everything except destructive >> actions, which is still reserved for the super user. As such a user a >> ran a script that did a "chip(10)", and got the following error: >> >> dtrace: error on enabled probe ID 3 (ID 13: syscall::read:return): >> invalid kernel access in action #2 >> >> > Pardon me, That should have been a "chill(10)". Sorry. > > Chip (not 10) ;-)Thanks alot. Its been a long time since I''ve read the manual. Should have known that...
Brian Kolaci wrote:> Chip Bennett wrote: > >> Chip Bennett wrote: >> >>> According to the manual, if you give all of the dtrace privs to a >>> normal user, that user can access everything except destructive >>> actions, which is still reserved for the super user. As such a user a >>> ran a script that did a "chip(10)", and got the following error: >>> >>> dtrace: error on enabled probe ID 3 (ID 13: syscall::read:return): >>> invalid kernel access in action #2 >>> >>> >>> >> Pardon me, That should have been a "chill(10)". Sorry. >> >> Chip (not 10) ;-) >> > > Thanks alot. > Its been a long time since I''ve read the manual. Should have known that... > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >Also, you would have to start the dtrace sccript with a -w option, if you do not, the destructive actions do not take. Actually, I think the script will not even run
Peter Shoults wrote:> Brian Kolaci wrote: >> Chip Bennett wrote: >> >>> Chip Bennett wrote: >>> >>>> According to the manual, if you give all of the dtrace privs to a >>>> normal user, that user can access everything except destructive >>>> actions, which is still reserved for the super user. As such a user >>>> a ran a script that did a "chip(10)", and got the following error: >>>> >>>> dtrace: error on enabled probe ID 3 (ID 13: syscall::read:return): >>>> invalid kernel access in action #2 >>>> >>>> >>> Pardon me, That should have been a "chill(10)". Sorry. >>> >>> Chip (not 10) ;-) >>> >> >> Thanks alot. >> Its been a long time since I''ve read the manual. Should have known >> that... >> >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >> > > > Also, you would have to start the dtrace sccript with a -w option, if > you do not, the destructive actions do not take. Actually, I think the > script will not even runYep, they knew that. But audit wants to make sure they can''t even do it by mistake (for example, hidden in the first line of a D script).
On Mon, Jan 14, 2008 at 02:34:53PM -0500, Brian Kolaci wrote:> A customer would like to run DTrace on some production boxes > however they need a way to prove that no destructive actions > can be taken, not even by accident. This "proof" is required > before they can do anything on the production boxes. > > Is there an executable or possibly an RBAC controllable > action that can be done to strip the "-w" functionality from > the DTrace executable? Or possibly strip some privileges that > won''t allow DTrace to do anything destructive?You can set the tunable dtrace_destructive_disallow which will do exactly what you require. Just add this line to /etc/system: dtrace:dtrace_destructive_disallow This is described in the documentation: http://wikis.sun.com/display/DTrace/Actions+and+Subroutines See toward the middle of the section titled ''Kernel Destructive Actions''. - ahl -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Mon, Jan 14, 2008 at 05:24:38PM -0800, Adam Leventhal wrote:> Just add this line to /etc/system: > > dtrace:dtrace_destructive_disallowThat should have been: set dtrace:dtrace_destructive_disallow = 1 - ahl -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
Brian Kolaci wrote:> Peter Shoults wrote: > >> Brian Kolaci wrote: >> >>> Chip Bennett wrote: >>> >>> >>>> Chip Bennett wrote: >>>> >>>> >>>>> According to the manual, if you give all of the dtrace privs to a >>>>> normal user, that user can access everything except destructive >>>>> actions, which is still reserved for the super user. As such a user >>>>> a ran a script that did a "chip(10)", and got the following error: >>>>> >>>>> dtrace: error on enabled probe ID 3 (ID 13: syscall::read:return): >>>>> invalid kernel access in action #2 >>>>> >>>>> >>>>> >>>> Pardon me, That should have been a "chill(10)". Sorry. >>>> >>>> Chip (not 10) ;-) >>>> >>>> >>> Thanks alot. >>> Its been a long time since I''ve read the manual. Should have known >>> that... >>> >>> _______________________________________________ >>> dtrace-discuss mailing list >>> dtrace-discuss at opensolaris.org >>> >>> >> Also, you would have to start the dtrace sccript with a -w option, if >> you do not, the destructive actions do not take. Actually, I think the >> script will not even run >> > > Yep, they knew that. But audit wants to make sure they can''t even do it > by mistake (for example, hidden in the first line of a D script). >Well, it really wouldn''t be hidden would it. It would have to be in the first line as an arg passed into dtrace. I guess I do not get it.....all they would have to do is more the script and see if it has a -w on the first line......