This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Proposal for PR 13128
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