Re: Proposal for PR 13128

[Dave Brolley <brolley at redhat dot com>]

Hi,

It has been pointed out, by Josh and Frank that some self-checking by 
the module itself will be necessary in order to handle the case where an 
older version of staprun is presented with a new module which has been 
signed for stapkern. In this case, the older staprun will load the 
module after verifying the signature, even if the user only has stapusr 
level privileges.

The new modules will contain generated code which is aware of the 
privilege level required to run the module. staprun will pass in the 
user's credentials (group membership) and the module will unload itself 
if the user's credentials are insufficient.

Note that the module self check is necessary and sufficient for a 
correct implementation, however having staprun check privilege levels 
before loading the module will prevent the rapid loading and unloading 
of modules by unauthorized users (a kind of DOS attack) and having two 
levels of checking certainly can't hurt.

I thought I would go through the various scenarios to ensure that we've 
thought of them all and that they're all covered. There are 3 variables 
to consider: old vs new staprun, new vs old modules, signed vs unsigned 
modules. When evaluating the scenarios, remember that, at a minimum, a 
user must be a member of stapusr to even execute staprun and that all 
signed and verified modules were created by a trusted systemtap 
implementation.

Any scenario involving an older version of staprun with old modules is 
as implemented today.  The new scenarios are:

Scenario 1: Old staprun + new, unsigned module
    - The module will only be loaded for root and members of stapdev

Scenario 2: Old staprun + new, signed module
    - staprun will verify the signature of the module
    - if verification fails
      - the module will not be loaded
    - if verification succeeds
      - staprun will load the module
      - staprun will not pass any user credentials to the module
      - The generated code in the module will assume that the user's 
credentials are stapusr (minimum).
      - If the module was signed for stapkern, the self check will fail 
and the module will unload itself. Note that this will, unfortunately, 
happen even if the user has stapkern credentials, however the old 
staprun cannot check this.

Scenario 3: New staprun + old, unsigned module
    - The module will only be loaded for root and members of stapdev

Scenario 4: New staprun + old, signed module
    - staprun will verify the signature of the module
    - if verification fails
      - the module will not be loaded
    - if verification succeeds
      - staprun will look for the privilege level within the module and 
will not find the section
      - staprun will assume that the privilege level of the module is 
stapusr (the minimum signed privilege level)
      - staprun will load the module, passing the user's actual credentials
      - The self check within the module will pass, since stapusr is 
the minimum privilege level.

Scenario 5: New staprun + new, unsigned module
    - The module will only be loaded for root and members of stapdev

Scenario 6: New staprun + new, signed module
    - staprun will verify the signature of the module
    - if verification fails
      - the module will not be loaded
    - if verification succeeds
      - staprun will look for the privilege level within the module 
(the section will be found)
      - if there is an error parsing data within the section, the 
module will not be loaded
      - if the user's privilege is less than required, the module will 
not be loaded
      - otherwise staprun will load the module, passing the user's 
actual credentials
      - The self check within the module will pass, since the use has 
the required privilege level
    - Note that not loading the module when there is an error parsing 
the privilege data allows for the future where this staprun is old and 
unaware of some new privilege level which may be higher than stapkern. 
This assumption will prevent a user with stapkern credentials from 
loading a future module which requires that higher privilege level. 
Although it is difficult to imagine a privilege level between stapkern 
and stapdev, we certainly shouldn't prevent one from existing!

Dave