[Rpm-maint] First attempt for the patch on extending the plugin interface for rpm

[Panu Matilainen]

On 10/15/2012 03:18 PM, Reshetova, Elena wrote:
> Hi,
>
> After reading your responses I think we indeed need to break this patch into
> at least two or three parts. It would help us to concentrate on one set of
> the hooks at the time and integrate them separately in steps.
> You mentioned that pre/post tsm/psm hooks are pretty much fine, so we can
> start from them.

Fine with me.

> I would propose to add to them a security plugin loading
> function and macros.

Obviously there needs to be some way of loading the plugins... What 
kinda bothers me here is the notion of "security plugin" - except for 
perhaps the signature/conflict hooks, there's nothing inherently 
security-specific here.

The two immediate candidates *are* security-oriented, but they're very, 
very different in what they do and how they affect the system. Eg if you 
disable SELinux labeling on a system where SELinux is enabled, you'll 
pretty much just shoot yourself in the foot (by ending up with a rather 
screwed up system) rather than fundametally bypass system security. 
"Transaction plugin" or something to that effect would seem to be more 
appropriate as these hooks could be used for all sorts of purposes 
(additional logging / interaction with other systems like dbus 
notifications for somebody ... whatever).

> Also, if there are no objections I would add here a
> ScriptSetup hook (it is rather simple one and outside of other hooks). This
> can be the first bunch that we can bring into shape to be acceptable for
> merge.

The script setup hook is fairly obvious too, just forgot to mention it. 
The one question with that is (again) the argument(s) it receives: 
currently its ARGV_t, but does it actually need the entire argv or would 
just the actual executable path suffice for the setup?

Another possibility might be passing an rpmScript "object" (which would 
need exporting and probably added interfaces, but that's kinda in the 
plans anyway at some point). But perhaps that's best left for later.

> Then after the above is hopefully merged I will start attacking the
> file-related hooks (I have already made a number of changes and will look
> into improving them further based on your comments). And at the end we can
> talk about how to integrate the rest.
>
> I will post the first bunch shortly if there are no objections.

Feel free to post as many revisions as you want, it tends to be more 
productive to discuss actual patches than hand-wavy abstractions :)

> Further comments are inline:
>
>> Actually, the ability to sanely disable these things from cli and API is in
> practise a hard requirement. The reason is that rpm is used in a large
> variety of situations beyond the basic "system package management"
>> task: creation of chroot (build-)environments that are nothing like what
> the system might be running, install/live images, certain per-user tasks,
> workarounds for weird setups etc. Plus all the things we never even imagined
> - by now I hope to have learned (the hard way) that no matter how unlikely
> it >seems, the unforeseen oddball (yet legal) cases always exist :)
>
>> I do realize that needs on an embedded / handheld systems can be
> drastically different from  a general purpose system. How to support "full
> lockdown" where needed but allow disabling for other uses is something to
> think about.
>
> Hm.. This isn't easy indeed. Can we make a security plugin a special case
> regarding to the cli? Meaning that if the rpm is compiled with
> "ENFORCE_SECURITY", then it isn't possible to disable the security plugin
> from cli and if loading/expanding of security plugin fails, then rpm stops.
> Providing cli or API option to disable additional security enforced by the
> plugin(s) even if security have been compiled in sounds scary for me....

I dunno... There are soooo many different options and API flags that 
affect these things, attempting to enforce things from the inside of rpm 
seems hopelessly futile: practically every aspect of rpm's behavior is 
overridable via cli, API and configuration. Including the paths where 
rpm loads its configuration from. You'd need to have a hard-wired list 
of mandatory plugins and their non-macro paths compiled rpm to enforce 
anything at all. And even then, if you have cli access as root, what's 
to prevent the user from just replacing the executable/libraries with 
something that doesn't enforce anything?

The way I see it, the only thing that can enforce the kind of MAC-style 
behavior you're after is the kernel:

In terms of SELinux (which is more familiar to me), it might be 
something like having rpm confined to very limited read-only 
functionality, and the plugin would request a transition to a context 
that where installations etc become possible. With that sort of setup, 
you can try to disable whatever you want on the cli/api/configuration 
but you're unable to *do* anything without having the "security" plugin 
loaded, turning the whole picture upside-down. Obviously there would 
have to be some kind of (signature?) mechanism of ensuring the plugin is 
actually authorized to request the extra privileges.

>> What I was thinking was more in the direction of "if plugin X returned
> failure, should we even call the other hooks" (such as falling back to
> something else if one of the involved filesystem doesn't support feature Y),
> but this is now something that neither the plugin or rpm has any way of
> actually knowing.
>> The point perhaps being, the exact semantics for the plugin hooks needs to
> be far more clearly defined sooner or later.
>
> I think even if plugin X returns failure on hook Z, we need to call the hook
> Z for all other plugins, because this will make sure that all plugins have
> the same set of hooks that got executed during the rpm transaction. Also, it
> would be up to each plugin to be prepared that rpm transaction can stop and
> fail outside of the plugin (inside rpm itself or inside of other plugins)
> and then be ready that only cleanup hook is called. So, for example, plugin
> might have pre tsm/psm hooks called and they go fine, but then some other
> plugin returns a failure on prepsm hook, so whole transaction goes to
> failure and plugin gets cleanup hook called even if from its point of view
> everything went fine.

Yup. My "issues" here are probably just a matter of adjusting my own 
thinking to the different style needed by plugins :)

>> FWIW, I've been considering exporting the fd digest API for quite some
>> time. That stuff probably needs a bit of polishing/sanitizing before
>> exporting, but I'm not at all opposed to doing it.
>
> Yes, I think this would be good and then it can be cleaner from plugin side
> to get digest calculated.

Ok. I'll try to have a look at it soonish.

>> For now, go for the absolute minimum exposure of rpm "objects". The
>> problem here is different from the other internals (such as fsm in the
>> previous versions) exposure, the issue here is that it exposes a ad-hoc
>> set of things that rpm currently happens to internally use to handle
>> this stuff. Which is not entirely unlike Lucas Arts adventure games of
>> old: you have a rope, two bananas and a fish, and you need to somehow
>> use those to cross the ravine to get the umbrella from the other side
>> that you need to... :)
>
>> The fact that the hook breaks in rpm >= 4.10 despite arguments remaining
>> the same kinda underlines the issue. Rpm internals are going through
>> some pretty fundamental changes at the moment, and this is one of the
>> places that will hopefully become saner when its all done (my wishful
>> thinking is to have at least the basics around in rpm 4.11 already).
>> When that happens we can export more, but right now its better to keep
>> things to minimum you can get by with.
>
> Agree, I will take a stronger attempt to reduce the arguments to the actual
> needed once
> for all the file hooks. I guess the conflict one is the most heavy one at
> the moment, so
> I will try to address it properly next time I post the patch for file hooks.

The conflict hook is indeed probably the worst "offender". Of course you 
really do want the full information such as in rpmfi to do informed 
decisions (at least without having to duplicate all the relevant data 
inside plugins, and I dont want to encourage that), the issue here is 
just the rpm-internal hysteria with internal/external interfaces, 
different representations of packages that are to-be-installed vs the 
already installed-ones etc. Lets leave worrying about the conflicts-hook 
till later.

>
>> The signature verification hook is another place where some weird
>> internal bits and pieces get passed around. That might be unavoidable,
>> dunno... but then (and I think I've said this before), signature
>> enforcing mechanism should really be in rpm core (and is sorely missed
>> currently). Plugins might further enhance / implement policy around
>> that, or something. Oh and I know this is hand-wavy and vague :-/
>
> Yes, I think it would be good to think more on this. I understood how you
> would like
>   to have it now and agree that this would be an ideal case. I will put this
> on my todo list
> to see how this can be done in a better way.

Ok, cool. The signature enforcement is something I've thought about on 
and off for quite some time. I don't recall the specifics offhand, but 
IIRC the issues tend to revolve more around legacy expectations of how 
things work, both from cli and API-user POV, than the signature 
enforcement itself.

>> What I referred to above is specifically the file conflict resolution
>> thing (and our previous discussion about that). Eg looking at the MSM
>> plugin, AFAICT it can let conflicts pass at this point, yet deny it deep
>> down from inside when the transaction is already in progress. There
>> always will be cases where a failure cannot be detected before actually
>> trying to install (ie, in fsm), but that should be the absolute last
>> resort, not something you'd ever see in "normal" operation.
>
> Sure, I guess this problem is about the actual hook content, not necessary
> the hook itself. I guess the hook should be redone to not simply log the
> conflict case and decide on it later, but actually decide before starting a
> transaction.

Yes, its indeed what the MSM hook does, rather than the hook itself, 
that bothers me. And more generally, the fact that such things become 
possible with plugins. I guess its not possible to really prevent, given 
sufficiently powerful plugin interface, but if nothing else the 
interfaces should encourage the "correct" usage and discourage working 
behind rpms back. Whatever that means - I do realize I'm just waving 
hands again :)

> I am quite sure I can change it in the plugin itself.

Ok, that'd be good. I was actually wondering why its done the way it is 
now - if there is an actual reason (such insufficient information 
available at that point), I'd like to understand it.

	- Panu -