This is the mail archive of the systemtap@sourceware.org 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


systemtap-owner@sourceware.org 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 - grundym@us.ibm.com

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]