[Rpm-maint] Tizen rpm security plug-in interface

Panu Matilainen pmatilai at laiskiainen.org
Fri Oct 28 09:18:31 UTC 2011


On 10/10/2011 04:00 PM, Reshetova, Elena wrote:
> Hi,
>
> Let me make first a short introduction and some explanation to you about the
> rpm
>   security related work we have been doing recently at Intel.
>   I hope we can collaborate on this in the future and help to put good
> enablers in rpm for security purposes.

Hi, and apologies for the late late reponse (starting to be my rpm-maint 
hallmark, sigh)

> Some history first:
> January this year, there was a set of patches posted from Tero Aho, you can
> find them in archives:
> http://lists.rpm.org/pipermail/rpm-maint/2011-January/002980.html
>
> I can see that even two tags were reserved for MSSF in rpm tags:
> RPMTAG_MSSFMANIFEST and RPMTAG_MSSFDOMAIN.
>
> These patches were intended for wiring a MSSF rpm security plug-in for MeeGo
> that
> would contain a rich set of security functionality, like setting up security
> policies for installed packages,
> labelling xattr for Smack and IMA and etc. I can provide more detailed
> description of functionality, if needed.
>
> As you probably heard, LiMo and MeeGo had merged into a new project, called
> Tizen (https://www.tizen.org/).
> This didn't eliminate by any means the need of security and similar security
> functionality that we needed in MeeGo related to rpm.
>
> So, our needs are still the same: we need to have a certain set of hooks in
> rpm during different phases of rpm installation that
> can be then implemented inside an rpm security plug-in. The hooks themselves
> didn't change, but we did change their realisation
> inside the plug-in, because we will be using a different security framework.
>
>
> I would like to get your opinion about the hooks' position in rpm code. I
> have just today rebased them to rpm master brunch.

Lets put it this way: with this work, I sense an opportunity to push the 
currently built-in selinux context labeling code into a plugin. Which is 
something I'd love to see.

> Please consider this not as ready patch, but more like code for the initial
> discussion.
> I have excluded for now the code of the plugin itself for simplicity.

More detailed description (especially the "why" part - see below) and a 
pointer to the plugin source itself to get an idea what sort of things 
its doing would be nice for starters. I'd expect there to be certain 
amount of overlap with selinux needs, and I would want to see MSSF and 
selinux share the same infrastructure (comparison is apples to oranges 
atm as part of selinux support is built-in and other parts in a 
collections plugin, which is a rather different beast).

Looking at the hooks defined by the security plugin...

What is the intended use case of SECURITYHOOK_FILE_CONFLICT_FUNC? Rpm 
doesn't allow conflicting files to be installed unless forced, so this 
seems a bit strange and/or redundant to me. Ditto for 
SECURITYHOOK_VERIFY_FUNC additional signature checking hook and the 
"allows calculating hashes" reference wrt the FSM-hooks - what's the 
rationale for these seemingly redundant things? Well ok, for signature 
checking, there's a fairly obvious rationale commented in the code long 
long ago:

     /** @todo Implement disable/enable/warn/error/anal policy. */

I just tend to think this is something that should be implemented in rpm 
core rather than plugins, but maybe you have a case that I fail to see.

Some hooks inside FSM are obviously going to be needed for the security 
labeling (for selinux as well), but the idea of exposing *anything* 
about of the existence (not to mention internals of it) of the FSM beast 
to plugins makes me cringe, to put it mildly. I'd expect the needs of 
security labeling to get by with far less information than passing a 
pointer to the entire fsm - we'll need to take a closer look at what's 
really needed there and limit the exposure of what's really rpm's 
deepest internal guts (and gory :)

SECURITYHOOK_SCRIPT_EXEC_FUNC is fairly obvious to me too (selinux would 
also want this). One thing I would've kinda expected but dont see here 
is a hook into package verification (ie rpm --verify), where a security 
plugin could check that whats on the system matches expectations for the 
"extra" security data.

As for the patch itself, before considering inclusion the unrelated 
stuff (reindenting pieces in rpmfc, redundant NULL-pointer checks on 
free etc) need to be pruned. But that's largely besides the point as you 
only posted this as a basis of discussion...

	- Panu -


More information about the Rpm-maint mailing list