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

Panu Matilainen pmatilai at laiskiainen.org
Wed Oct 17 08:23:47 UTC 2012


On 10/16/2012 07:31 PM, Reshetova, Elena wrote:
> Hi,
>
>> 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).
>
> Ok, let's call it indeed a "transaction plugin" because security plugin can be
> considered as a particular case of transaction plugin. I will rename it.

Thanks. That's the way I see it as well: additional security is just one 
possible application for transaction plugins.

>
>> 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?
>
> I am fine with just the path, but looking to SELinux code, the rpm_execcon()
> func needs the whole argv struct.
>
> @ Stephen, do you know how mandatory for SELinux is to have the whole argv
> struct? Is it just because of rpm_execcon() API or?

Like Stephen already replied, the entire argv is only needed for the 
performing the actual exec through rpm_execcon().

>> 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.
>
> Yes, I guess there is always a possibility  to change these things when better
> objects/structs are available. I am quite sure I can make these changes later
> since I will be responsible for introducing these hooks at the first place :)
> I don't just plan to dump this on you once and go away!

Good to hear :)

>> 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 theirr 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?
>
> We can prevent user or malicious app from modifying the rpm itself, its
> plugins, configuration files by using the MAC (as selinux or smack) in
> run-time and integrity protection (as IMA/EVM) for offline protection. Using
> librpm directly by user or program actually should be quite safe, because user
> or malicious app won't get any powerful permissions in the most restrictive
> setup (no classical root, no posix capabilities). There normally would be some
> higher level package manager on top of rpm that would have needed permissions
> and would execute rpm (which would inherit the permissions in this case) with
> a proper set of cli arguments and environment. If everything goes well, then
> we don't need to worry that rpm would install smth without a plugin being run.
> But what if the system gets damaged somehow (not even necessary attacked) and
> plugin binary happen to disappear? In this case given that we are relying on
> additional checks for the plugin, it is a very bad idea to proceed without it.
> It would indeed make the whole system unsecure and in addition also unusable,
> and this is all even without user understanding that system got corrupted. So,
> this was the idea behind having this "plugin present" check and stop if failed
> in place.  I was looking at it as some kind of analogy to sysinit that can
> make checks during the boot process that needed services (example from
> security: device lock daemon) are up and if they aren't up, then it can stop
> the boot and actually go to some recovery mode.
> Does this explanation makes a bit more sense?

So its more of a sanity check than an actual security measure. Nothing 
wrong with sanity checks, and I'm fine with having *any* configured but 
missing transaction plugin abort the transaction.

It's the case of non-configured plugin(s) somehow aborting that I find 
troublesome. The notion of mandatory plugins seems a bit alien to me, 
especially since rpm certainly does not *need* any transaction plugins 
to function as it always has. That's the reason I suggested the reverse 
setup where rpm is just totally incapacitated by external policy 
*unless* the necessary plugin is loaded.

The kind of setup where things simply fail because of missing, required 
plugin should be applicaple to various other cases too, through various 
means. For example assume that we moved the file capability handling to 
a plugin: the plugin could be made responsible for advertising the 
'rpmlib(FileCaps)' rpmlib-feature, and when the plugin is not loaded 
(for whatever reason), an attempt to install packages having file 
capabilities would just fail with missing dependencies. That can still 
be "worked around" by --nodeps but at that point its certainly no 
accident and you're knowingly shooting your own foot :)

	- Panu -


More information about the Rpm-maint mailing list