[Rpm-maint] Unified set of security hooks for rpm

[Panu Matilainen]

On 09/14/2012 02:52 PM, Reshetova, Elena wrote:
> Hi,
>

Hi,

>
> I have been writing to the list a while back proposing a set of security
> hooks that we need for rpm in Tizen.
>
> I have discussed with SELinux guys (in CC) and we agreed that can should try
> to define a unified interface that they can also use.
>
> This would allow to move currently partly integrated SELinux code outside of
> rpm to the security plugin code.
>

Yup. Like said in the past, getting the partly integrated SELinux stuff 
out of rpm core is something I would love to see.

>
> One question that we have is what is the best way to define a plugin
> interface for rpm?
>
> Should we define just security-related hooks and embed currently existing
> collection plugin hooks  into it
>
> or are there any plans for bigger rpm plugin interface that security hooks
> should be part of?

Good question... The current collection hooks aren't really "security" 
at all but something else. Yet the selinux policy plugin does kinda fall 
into that category, and if there's an entirely different plugin type 
needed for actually putting the security labels (retrieved by eg 
collection plugin) and such into place, requiring different plugins to 
interact somehow, and that I suppose would get ugly real fast.

There are some other places that could use plugins as well that would 
fall into entirely different categories. Just as an example, one such 
thing is translations of i18n header strings from external sources (eg 
specspo which exists in at least two different flavors, one upstream and 
one in Fedora) that could be cleanly handled (and would open up new 
possibilities) with plugins.

>
> I can start working on the patch to define the combined set of hooks as soon
> as I am sure I am not going to do
>
> smth that  is fully unaligned with rpm future plans.

Just FWIW / food for thought, back some time ago I had a brief look at 
isolating the "security" activity into a relatively abstract "security 
manager" object (instead of plugin hooks littered all around), which 
could actually be a stack of different bits and pieces implemented by 
plugins (SELinux/MSS labels, maybe file capabilities etc) but that ran 
into all sorts of issues right on the first steps already. Whether I 
just didn't pursue it hard enough or just not a feasible approach I 
dunno but suspect the latter to be the case.

As for the actual hooks, I think we just need to look at the existing 
and planned needs of the security labeling etc stuff one by one and try 
to figure whether it all needs to go into a giant "transaction plugin" 
interface or whether it's actually possible to categorize them into 
tidier sets.

Some other plugin possibility examples: the different rpmio 
(de)compression types would fit the plugin use-case spot-on. Whether 
having them as plugins actually makes sense is another question, but it 
presents some interesting issues: the rpm file io subsystem lives in 
librpmio, suggesting the core plugin infrastructure should be there as 
well, instead of librpm itself. However they would need to be able to 
register themselves into rpmlib() provides which live in librpm, in the 
transaction "layer"...

The ability for plugins to register custom rpmlib() provides seems 
generally useful, eg the SELinux/MSSF stuff might want to do it too and 
I can imagine other cases as well. And the needs of plugins wanting to 
advertise themselves through rpmlib() provides differ vastly - from very 
low-level file io to the rather high-level collections and whatnot.

The only thing I know for sure is that there are needs (or at least 
opportunities) for more than one plugin type, and the different types 
should be able to share the common basic plugin manipulation (loading 
etc) infrastructure.

	- Panu -