[Rpm-maint] [PATCH 1/2] Extending rpm plugin interface, part 1

[Panu Matilainen]

On 11/12/2012 10:50 AM, Reshetova, Elena wrote:
>> Scripts run with all the powers that rpm itself has, and there's not a
> whole lot that can be done about it: scriptlets expect to, and often need
> to, do all sorts of crazy things.
>
> True, but we would actually like to be able to limit things that scripts can
> do. It is ok for a script to create a new file or to call ldconfig, but in
> our setup it is not ok for script to start relabeling the xattrs on
> filesystem (you can do this with CAP_MAC_ADMIN for example) or rewriting
> important system files (you can do this with CAP_MAC_OVERRIDE and
> CAP_DAC_OVERRIDE).

Understood, and I see nothing wrong with wanting to limit the damage 
rogue/runaway scriptlets can do. If you control the entire package set 
and compatibility with arbitrary 3rd party "big vendor" packages (which 
are the ones that traditionally do utterly crazy things) isn't an issue 
then certainly some level of added control is possible.

>
>> The differences from regular exec()'ed scripts and Lua-ones are basically:
>> - As Lua scripts run in the rpm process space, some extra protection is
> needed, like saving + restoring current working directory, umask and
> preventing Lua scriptlet from exec()'ing or exit()'ing the process.
> Just out of interest, is there are reason for them actually to run in rpm
> process space as opposite to doing the same as for regular scripts?

The most important use-case is to make it possible to run scripts when 
even /bin/sh is not available. Such as %pretrans scripts on initial 
install - there simply nothing to exec() in that environment. Or if the 
package containing /bin/sh or one of its dependencies needs scripts, 
there's no other choice than an embedded script during initial install.
Related to that, one can avoid problematic external dependencies in the 
early "bootstrap" stages of initial install.

It also allows some things that aren't really possible otherwise, such 
as manipulating macros and "communicating" with other packages through 
the global Lua environment (and in theory, accessing rpmdb but that's 
not implemented), which would not be possible in an externally executed 
script.

It would be possible to fork() for the execution of embedded scripts 
without compromising the main use-case of early install, but it would 
break some possible uses of the second group. Whether that's a good or 
bad thing... is a different question. I dunno if anybody is actually 
using the current possibilities in that area.

>> - There are no context switches for Lua scripts in SELinux world
>> currently: Lua scripts run with rpm_exec_t context, "regular" scripts run
> with rpm_script_t. But both are practically omnipotent contexts, because
> they have to be.
>
> Stephen, do you have any plans related to Lua-scripts?
> I guess the reason it wasn't touched so far is the same as for us: when
> script is run in the same context, very little can be done to make it with
> little priviledge and still be able to continue rpm operation.

See above, I suppose we could add a configuration/compile-time switch or 
such to fork() the embedded script execution and then you wouldn't have 
to worry about getting the privileges back.

>
>> Oh, I meant the common pre- and post-hook pattern seems like it would make
> sense for scripts too in any case, regardless of whether it helps solving
> the context issue. It *might* in the SELinux case, but a post-hook could
> have some other entirely different uses, and it'd make the whole thing a bit
> more >symmetric :)
>
> Sure, I can make the hooks to follow the same principle. Just I would need
> to understand how the post-hook would be used in order to figure out proper
> arguments and decide if we want it to be called if script fails or not.
> I guess I would rather call post-hook then even if script has failed, but
> juts indicate the failure. What do you think should be the argument of
> post-script hook? Return code from the script (to know if it failed or not)
> and maybe script path again then?

Good question... symmetry is usually good, so I guess the post-hook 
should be always called if pre-hook was called. Script path + return 
code as arguments seems like a reasonably starting point at least. (I'm 
not really even dreaming of getting every single detail 100% right the 
first time :)

And like said, I think the plugin hooks should get called with embedded 
scripts too. It'll probably need another argument to let the plugins 
know whether an internal or external script is about to be executed - 
you could eg just deny execution of internal scripts from non-trusted 
sources then, without disabling lua entirely.

	- Panu -

>
> Best Regards,
> Elena.
>