|Main Archive Page > Month Archives > selinux archives|
After reading your responses I think we indeed need to break this patch into
at least two or three parts. It would help us to concentrate on one set of
the hooks at the time and integrate them separately in steps.
You mentioned that pre/post tsm/psm hooks are pretty much fine, so we can
start from them. I would propose to add to them a security plugin loading
function and macros. Also, if there are no objections I would add here a
ScriptSetup hook (it is rather simple one and outside of other hooks). This
can be the first bunch that we can bring into shape to be acceptable for
Then after the above is hopefully merged I will start attacking the
file-related hooks (I have already made a number of changes and will look
into improving them further based on your comments). And at the end we can
talk about how to integrate the rest.
I will post the first bunch shortly if there are no objections.
Further comments are inline:
>Actually, the ability to sanely disable these things from cli and API is in
practise a hard requirement. The reason is that rpm is used in a large
variety of situations beyond the basic "system package management"
>task: creation of chroot (build-)environments that are nothing like what
the system might be running, install/live images, certain per-user tasks,
workarounds for weird setups etc. Plus all the things we never even imagined
- by now I hope to have learned (the hard way) that no matter how unlikely
it >seems, the unforeseen oddball (yet legal) cases always exist :)
>I do realize that needs on an embedded / handheld systems can be
drastically different from a general purpose system. How to support "full
lockdown" where needed but allow disabling for other uses is something to
Hm.. This isn't easy indeed. Can we make a security plugin a special case
regarding to the cli? Meaning that if the rpm is compiled with
"ENFORCE_SECURITY", then it isn't possible to disable the security plugin
from cli and if loading/expanding of security plugin fails, then rpm stops.
Providing cli or API option to disable additional security enforced by the
plugin(s) even if security have been compiled in sounds scary for me....
>What I was thinking was more in the direction of "if plugin X returned
failure, should we even call the other hooks" (such as falling back to
something else if one of the involved filesystem doesn't support feature Y),
but this is now something that neither the plugin or rpm has any way of
>The point perhaps being, the exact semantics for the plugin hooks needs to
be far more clearly defined sooner or later.
I think even if plugin X returns failure on hook Z, we need to call the hook
Z for all other plugins, because this will make sure that all plugins have
the same set of hooks that got executed during the rpm transaction. Also, it
would be up to each plugin to be prepared that rpm transaction can stop and
fail outside of the plugin (inside rpm itself or inside of other plugins)
and then be ready that only cleanup hook is called. So, for example, plugin
might have pre tsm/psm hooks called and they go fine, but then some other
plugin returns a failure on prepsm hook, so whole transaction goes to
failure and plugin gets cleanup hook called even if from its point of view
everything went fine.
>FWIW, I've been considering exporting the fd digest API for quite some
>time. That stuff probably needs a bit of polishing/sanitizing before
>exporting, but I'm not at all opposed to doing it.
Yes, I think this would be good and then it can be cleaner from plugin side
to get digest calculated.
>For now, go for the absolute minimum exposure of rpm "objects". The
>problem here is different from the other internals (such as fsm in the
>previous versions) exposure, the issue here is that it exposes a ad-hoc
>set of things that rpm currently happens to internally use to handle
>this stuff. Which is not entirely unlike Lucas Arts adventure games of
>old: you have a rope, two bananas and a fish, and you need to somehow
>use those to cross the ravine to get the umbrella from the other side
>that you need to... :)
>The fact that the hook breaks in rpm >= 4.10 despite arguments remaining
>the same kinda underlines the issue. Rpm internals are going through
>some pretty fundamental changes at the moment, and this is one of the
>places that will hopefully become saner when its all done (my wishful
>thinking is to have at least the basics around in rpm 4.11 already).
>When that happens we can export more, but right now its better to keep
>things to minimum you can get by with.
Agree, I will take a stronger attempt to reduce the arguments to the actual
for all the file hooks. I guess the conflict one is the most heavy one at
the moment, so
I will try to address it properly next time I post the patch for file hooks.
>The signature verification hook is another place where some weird
>internal bits and pieces get passed around. That might be unavoidable,
>dunno... but then (and I think I've said this before), signature
>enforcing mechanism should really be in rpm core (and is sorely missed
>currently). Plugins might further enhance / implement policy around
>that, or something. Oh and I know this is hand-wavy and vague :-/
Yes, I think it would be good to think more on this. I understood how you
to have it now and agree that this would be an ideal case. I will put this
on my todo list
to see how this can be done in a better way.
>What I referred to above is specifically the file conflict resolution
>thing (and our previous discussion about that). Eg looking at the MSM
>plugin, AFAICT it can let conflicts pass at this point, yet deny it deep
>down from inside when the transaction is already in progress. There
>always will be cases where a failure cannot be detected before actually
>trying to install (ie, in fsm), but that should be the absolute last
>resort, not something you'd ever see in "normal" operation.
Sure, I guess this problem is about the actual hook content, not necessary
the hook itself. I guess the hook should be redone to not simply log the
conflict case and decide on it later, but actually decide before starting a
I am quite sure I can change it in the plugin itself.
-- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to firstname.lastname@example.org with the words "unsubscribe selinux" without quotes as the message.