On Tue, 2012-09-11 at 14:56 +0300, Elena Reshetova wrote:
I agree that it is better to have one plugin interface for rpm that
can be used either for security or other purposes. However my current
understanding is that the only interface for plugins that rpm has
is a
"collection plugin". I don't have anything against it, but do we need
that notion for set of generic security rpm hooks? I don't think
every
plugin needs to be aware about what is a "collection" and how to
handle it. I would prefer a simpler approach when a set of hooks is
defined and then called at different stages of the rpm execution.
I would tend to view the collection hooks as just part of the overall
hook interface for plugins. You are defining per-transaction,
per-package, and per-file hooks, and per-collection hooks are just
another case to consider (unless I misunderstand). But as I wasn't
the
one who came up with the collection hooks, others may have other
opinions (Steve? Jim?).
Another issue is that I would like to be able to mandate the presence
of a plugin in a system in some cases. For example for our
platform, I
would like to tell that if loading of our security plugin fails, then
installation must be aborted. I think current plugin interface
doesn't
provide a way to do it either.
If not, I don't see why it cannot be made to support that
functionality.
It isn't truly unique to security; other kinds of functional
plugins may
need/want to be able to abort the installation.
Yes, you are right, this hook needs changing. The reason why
initially
we didn't need more arguments is that the plugin remembered needed
info from the FSM_OPENED hook (like path for example) and then in
FSM_CLOSE used this info. However, I have just changed things a bit
and I think now the interface can be smth like:
rpmRC SECURITYHOOK_FSM_CLOSED_FUNC(const char* dirName, const char*
baseName, mode_t mode, int rpmrc)
I have noticed that SELinux uses fsm->path directly, do you prefer to
have that one passed to the hook or dirName + baseName is ok?
As long as we can reliably determine the full path from the inputs, I
don't think it matters.
About the selabel handle: I would prefer to keep any plugin internal
data outside of actual rpm. It helps to keep the rpm and plugin
independent with only dependency on the actual hooks. The way we
handle it in our plugin is that this info is preserved in the plugin
state while package processing is going. Would any such approach be
acceptable for selinux?
Another option to go about it would be to define a handle for each
plugin's data as simple void pointer and then pass this handle to the
plugin in everyhook. Internally plugin can store any stuct behind
this
including any needed handles. But I think this won't be much
different
for the plugin than storing this by itself.
I'm unclear on this point; possibly others (Steve?) will have more
insight. We appear to be maintaining a per-rpmts selabel handle at
present, and refreshing it under various conditions. I know that our
situation is complicated by the fact that policy may change either
as a
result of explicit policy in the rpm package using the plugin
mechanism
or as a side effect of a %post scriptlet in the rpm package (the
original way of packaging policy which is still in widespread
use). So
I am uncertain as to whether it suffices to maintain this state
globally
within the plugin or whether we truly need to be able to hang a
selabel
handle off of the rpmts in some way and track its life cycle.
And fsmMkdirs() is actually a good point! I am wondering what
would be
the proper way to handle this part. I think it might make sense to
define a new hook just for this purpose, because this hook would be
called only once per package versus the FSM_CLOSED that is called
once
per every file in the package. The interface can be similar to CLOSED
hook:
rpmRC SECURITYHOOK_FSM_MAKE_DIR_FUNC(const char* dirName, const char*
baseName, mode_t mode)
What do you think?
Yes, I think that makes sense.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing
list.
If you no longer wish to subscribe, send mail to
majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
