Re: Proposal for PR 13128

[fche at redhat dot com (Frank Ch. Eigler)]

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