Re: Proposal for PR 13128

[Dave Brolley <brolley at redhat dot com>]

On 09/30/2011 01:14 PM, Frank Ch. Eigler wrote:
> > [...]
> > 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.
Yeah. That was a cut and paste error.
> > [...]
> > 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.
The general intent is that our new-staprun should be wary of far-future 
modules which contain information that it does not understand. If you 
want to mandate that any such far-future modules contain bullet-proof 
self checking code, then that's your call. However, it could lead to the 
possibility of rapid load/unload of modules which is part of the reason 
why we're implementing privilege checking in staprun in the first place.

Our philosophy with the unprivileged support has always been to assume 
the worst unless proven otherwise. It seems strange that we bother with 
a privilege level check at all in staprun for current modules if we're 
going to go ahead and load future-modules containing unexpected 
privileged data.
> 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.
I agree with jistone's proposal about it simply being a list of the 
groups which can load the module in plain text.

>    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.
Addition section(s) containing arbitrary data are, of course possible.

Dave