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 -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
