This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Proposal for PR 13128
Hi, Dave -
brolley wrote:
> [...]
> I thought I would go through the various scenarios to ensure that
> we've thought of them all and that they're all covered. [...]
Thank you! It looks all good, except for a few bits:
> [...]
> Scenario 4: New staprun + old, signed module
> [...]
> - 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.
In the old (current) case, there is no self-check within the module, so
it will pass by default. This is OK: it'll be an unprivileged one.
> [...]
> Scenario 6: New staprun + new, signed module
> [...]
> - 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!
I'm not so sure that's a good idea. Consider another step along our
degrees-of-freedom: new staprun + far-future signed module (with other
privilege levels supported). That module would self-check, but it may
do so based upon information other than just staprun would send it.
By having new-staprun reject it before module-init, those far-future
modules would be blocked by new-staprun.
Have you given any thought as to the format of the new elf note(s)?
It'd be nice to have them be dead-simple. It'd also be nice to add
another to fit in some more data about the versions, script
names/parameters, users, compilation client/server addresses,
timestamps.
- FChE