This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: FW: Re: pre-compiled systemtap modules - try2 feature request

Wow, I was not thinking along those lines of masks and run-time security
verification at the probe level. Most of our developers and users don't want
to dive into the OS in that kind of detail. They want to stay in the
application domain as much as possible. We have a lot of developers and
users we are transitioning over from Solaris to Linux and have never had the
chance or desire to get up close and personal with the OS.

For the most part, Michael's list is more than sufficient for our needs. The
only thing I would add is the ability for particular gids to probe the -RT

For the most part I was just looking for something simple. A lot of our
script use cases are not ad-hoc and would have formal
requirements/design/test/maintain processes in place.  

Thinking out loud, some of our use cases would be:

1) Pre-scripted for the Systems and Test Engineers/Scientists:
Inject faults into system and watch faults propagate through system or be
caught by the fault tolerance mechanisms.
Observe system perturbations/reactions and stabilization at much finer time
granularity than SNMP. (Closed servo loop response)
Statistical analysis of scheduling and I/O events and parameters triggered
at interesting times.
Collection of data to be used in system simulation models of the system.
Peek at shared and DMA memory areas. 

There are probably more cases that will be invented.

2) Ad-hoc scripts for the Developer/test engineer: Real-time process debug 

Why an interrupt did not get serviced in time.

Debug a cyclical process works 99.99% of the time but fails every few weeks
i.e. keep a ring buffer of interesting data and only dump it when a deadline
is missed.

Peek at what syscalls a commercial product is making

Why a soft_irq is consuming a lot of CPU time

I'll have a better idea of our needs this Thursday.


> -----Original Message-----
> From: Michael Grundy []
> Sent: Monday, September 18, 2006 9:57 AM
> To:
> Cc: David Sperry
> Subject: Re: FW: Re: pre-compiled systemtap modules - try2 feature request
> wrote on 09/18/2006 08:43:06 AM:
> > Hi, David -
> >
> > > > We are aware of this need, and work is in progress as we speak to
> > > > promote this style of usage.  Do you have any suggestions about what
> > > > form the "blessings" might have?
> > >
> > > For the next couple of years the security blessing is fairly simple.
> The
> > > user cannot have root access to the file system, capture or read other
> users
> > > passwords, impersonate another user, or bypass kernel auditing.  [...]
> >
> > What I meant to ask was whether you had any thoughts about how such
> > blessing (permission to run some particular systemtap script) might be
> > encoded into software.
> I was thinking before the module was loaded, stpd could look at the
> permissions granted to the user running the tap script and pass a
> permissions mask to the module. Those permissions would determine whether
> certain probes could be activated or not. Some permissions could also be
> handled by the same mechanism that does pid filtering.
> Examples of permissions would be:
> allowed to probe processes of own userid
> allowed to probe processes of any uids
> allowed to probe processes of specified gids
> allowed to probe suid processes
> Allowed to probe system calls
> allowed to probe vmm functions
> allowed to probe network functions
> allowed to probe vfs functions
> allowed to probe auditing functions
> You could even granulate guru mode, e.g. allowed to run c code, allowed to
> modify memory etc.
> When the module is built, the classification of function group can take
> place (is it a syscall, is it an auditing function). Then when the probes
> are set, a quick check of the mask to determine if they can place the
> probe.
> Things like uid permission could happen either at the probe level (probe
> fires, check mask to see if information can be captured) or the userspace
> level (filter out data user not allowed to see). And I apologize for the
> vagueness on the last bit, I didn't read the code before I wrote this.
> High traffic functions could be flagged into a separate group, to limit
> the
> amount of overhead a user can put on the system.
> Thanks
> Mike
> =========================================
> Michael Grundy -
> Knowledge is of two kinds.
> We know a subject as our own,
> or we can find information on it.
>                          - Irma Rombauer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]