[Rpm-maint] FSM hooks for rpm plugin
pmatilai at laiskiainen.org
Wed Feb 27 09:14:15 UTC 2013
On 02/27/2013 08:18 AM, Reshetova, Elena wrote:
>> Right, no surprises: there is an issue with hard links :)
> Oh, this is smth I should have actually remembered, but forgot :( I saw the
I forgot the specifics of hardlinks too, no worries :)
> issue a while back on our system setup, but since from security labelling
> hard links aren't interesting (security context should be set on a file
> itself, not a hard link), I simply didn't call hooks for hard links. But I
> agree that it might be important to know that they will be created and I guess
> in this case we would need to know when and where it goes. Actually not from
> labelling point of view, but from general security, a tightly configured
> system might have restrictions on where files/dirs/links are created. For
> example, it might not allow creating hard links in certain paths (in order for
> system to stay well arranged or for example in order to avoid untrusted
> packages creating hard links in sensitive dirs). The thing here is that such a
> check should be probably performed before we start to run FSM and unpacking
> the archive (for the same reason as conflicts).
Yup, restrictions would need to be enforced early on, FSM is too late.
> So, then if we consider that
> labelling and policy enforcement aren't valid use cases here, we only have
> informational use case left: plugin wants to know the links and their location
> as for any other files. Should we then create separate hook/call same hook
> (with modified parameters) actually at the moment when links are created
> (later on)?
Hmm. Good question... arranging pre/post-commit in fsmCommit() hooks
should be trivial. Although by now, I'm actually starting to wonder
whether it really makes sense to call any hooks for skipped files
afterall. The "informational use cases" could just go and look at the
package file list and their states from psm pre/post-hooks.
Looking at this, I just realized that rpm is currently doing chmod(),
chown() and all for each hardlink it creates, which just doesn't make
sense because ... by the very definition of a hardlink, it doesn't.
Probably worth fixing regardless of what we end up doing with hooks, eg
additional "setmeta" argument to fsmCommit() whether it should just
create or set the additional metadata as well, and have pre/post-commit
hooks get that so plugins get notified of all file creations but also
can avoid redundant setting of labels etc.
I'm going to poke around with this a bit to see what would make most
sense, now that I have sufficient selinux plugin code to test it with.
Like said, I'm starting to have second thoughts on the skipped files, so
I'll probably look at changing the existing hooks to the "commit model"
rather than add more: for actually created (and removed) files, the hook
semantics would be rather obvious. With skipped (and some delayed and
whatnot) files it gets far more convoluted. If it turns out the plugins
*really* need the skipped file info as well, we can always add (back)
more hooks later on :)
>> Regardless of how exactly the hardlinks are handled, perhaps we should pass a
>> pointer to the entire stat struct instead of just st_mode to the hooks,
>> that'd at least allow plugins to know they're dealing with hardlinks (and
>> various other possibly useful >information).
> I guess this is true, should be easy to change.
>> A different issue (much easier and one that we already discussed iirc) is
>> that I think we must check the return code from
>> rpmpluginsCallFsmFilePost() and allow it to fail, otherwise its not possible
>> to preserve the current behavior where eg failure to set SELinux context (or
>> other similar security thing) causes package installation to fail.
> I am always very supportive for giving more power to the plugin :) I think
> that it is possible to setup a system that failure to set a security context
> for files from the package might not result in security compromise, but then
> it might make package unusable and the effort required to do this is much
> bigger (we would need to play with security context of running rpm, which
> isn't that great). So, yes, I guess failing in this case is the easiest way.
Nod. Also since rpm itself will abort the install if setting metadata
fails, it seems only fair that plugins have the same power.
>> The good news is that other than the two above issues, the plugin API seems
>> to work quite nicely for SELinux.
> These are really good news! I was expecting more problems actually in
Heh. I wasn't actually expecting much problems because the selinux stuff
is pretty simple and straightforward, especially compared to the MSSF
stuff. But its always good to see theory and practise mostly agreeing :)
- Panu -
More information about the Rpm-maint