This is the mail archive of the
mailing list for the systemtap project.
Re: FW: Re: pre-compiled systemtap modules - try2 feature request
- From: Michael Grundy <grundym at us dot ibm dot com>
- To: systemtap at sources dot redhat dot com
- Cc: David Sperry <dave_sperry at ieee dot org>
- Date: Mon, 18 Sep 2006 09:57:14 -0400
- Subject: Re: FW: Re: pre-compiled systemtap modules - try2 feature request
email@example.com 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.
> > user cannot have root access to the file system, capture or read other
> > 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
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.
Michael Grundy - firstname.lastname@example.org
Knowledge is of two kinds.
We know a subject as our own,
or we can find information on it.
- Irma Rombauer