[Rpm-maint] FSM hooks for rpm plugin
pmatilai at laiskiainen.org
Tue Mar 12 08:46:03 UTC 2013
On 03/11/2013 02:14 PM, Reshetova, Elena wrote:
>> Yup, rpm pretty much has to trust its plugins. OTOH... this made me think of
>> another related issue: it would actually be better to set the permissions etc
>> before moving the file to its final location. Currently we first move the
>> file and then start setting permissions, which means executables and all will
>> for a >short period of time have totally incorrect permissions, labels and
>> all. So if you happen to execute that binary during that period, who knows
>> what will happen: it could fail to execute at all, execute with wrong
>> capabilities / labels etc.
> Yes, this would be the safest way of doing it. But it isn't that bad in the
> current scenario: if your security settings are proper (like labels of rpm
> itself and etc.), noone would be able to even access the tmp files before the
> proper labelling is in place. But agree: doing it right from beginning is even
> better and removes possibility of bad setup.
Yup, its probably more of a usability / update robustness issue than
security: in the current way of things, files that should be accessible
and executable are not so for the small period of time it takes getting
from rename() to chown(), chmod() etc. So for example if 'ls' executed
precisely at the wrong moment during upgrade of that package, you can
get permission denied for the executable. Setting permissions on the
temporary name would avoid that unnecessary temporary breakage, but then
live-updates can never be truly fixed.
>> Setting the permissions before moving would fix that and also avoid replacing
>> a previous file at all in case we fail to in one of the metadata steps. For
>> the stock metadata the actual path makes no difference, but for security
>> labels you'd want the final path though (to avoid having to figure out and
>> strip the >temp extension from the file), so it'd require passing two paths
>> to the pre-commit hook: current and final.
> Maybe it is the fact that I had to wake up 3am today to come back to Helsinki,
> but I don't understand why do we need to know the final path for security
> labels labelling? I don't think file is labelled based on its destination: it
> is more like based on what is inside package, manifest, device security
> policies and etc.
It's needed for things where the label does not come from the package
but system policy, exactly because we lay the disk on temporary name
first. At least with SELinux the label is (automatically) set at
file/directory creation time based on its path, and rename() does not
automatically relabel it. And because rpm creates the files with
temporary names, the initial labels are "always" wrong and we need to
manually adjust them for the final path.
Of course it would be possible to just leave such things for post-commit
where we already have the final path, that would be exactly the same as
what currently happens. It just means missing the opportunity to get it
right early, eliminating one window of live-update breakage (and an
opportunity to bail before committing the file at all on errors).
- Panu -
More information about the Rpm-maint