Hi, I am attaching next version of the scriptlet-related patch. Next I will go back to current hooks and make a small patch to make sure they are called as we agreed. Will do this tomorrow. Also some comments below:
> There's eg RPMRC_NOTTRUSTED that could be (ab)used for certain types of security-related failures, but what if we have several plugins on a hook, one returning RPMRC_OK, another one RPMRC_FAILED and the third one RPMRC_NOTTRUSTED - which >one should the CallFooHook() function return? >One of the failures sure but... The security theory is very easy for this case: the most restrictive case/result is applied/returned. So, in this case I would return that we failed on policy and indicate it with " RPMRC_NOTTRUSTED ". In this way rpm can always enforce the strictest rule, for example if it wants to abort installation after receiving RPMRC_NOTTRUSTED. > One possibility could be a bitfield type return code, where each plugin can raise relevant bits of fairly generic categories. There's no telling which plugin raised what bits, but at least it'd be possible to reflect more than one kind of failure per hook then. >But again, mostly just something to keep in mind / think about for now. This would be cool, especially if we get LSM stacking accepted upstream! Now there are active discussions on security mailing list on Casey's patches and I can imagine that in the some distant future we can have a number of simultaneous LSM working with rpm and a number of plugins that can use it. And for each plugin we can log what happens and make rpm to be more aware. But you are right: this is just future so far... > We could just make the hook return "void", but perhaps its better to let the hooks return errors codes and let rpm filter out (and perhaps log a >warning) what it cant handle: its possible that some things it can't handle now can be handled at some point in future. Agree, I think it is good to give plugins possibility to complain, even if the complains aren't heard at the moment. I just meant that maybe no reason to invent new return codes just yet. > Note that rpm always creates files (but not directories) with a temporary extension, and they're only rename()'d to final location (which might replace existing files on upgrades) after everything was successfully unpacked to the temporary locations. Rpm >doesn't currently do a proper job of cleaning up the cruft in case of failure, but there is a chance to undo at least some of the things before the fsm "commits" >the files to final destination. Oh, this is actually very good, but I am not sure this is full solution. I guess I need to study fsm machine more deeply. It is the hardest one for me to understand so far :( Let's imagine we install a package and while putting its files to temp. location security labelling fails on one of them (maybe even not the first file and this is the bad thing). Plugin returns failure on that file in file closed hook (which in this case would need to be moved before FSM commit). What would be the proper behaviour? IMO we need to revert the whole package installation unfortunately. Because if file is left on filesystem but not properly labelled, then it might not be usable, and this might also lead to app/service/daemon/whateverinstalledfrom package not usable too. Do we want such package on the filesystem then? But then the problem how do we remove the files that has already been commited or if this file happens to be a dir? >At least in SELinux, rename() doesn't affect the security labeling so it'd be possible to set the final contexts on the temporary files and only if that succeeds for all files, commit the result. Currently the labelling is done on the final destination so there's not >much chance of undoing in case of failure. Hm, isn't rename just a sub-case of mv? I think in this case, xattrs might not be preserved (for example for cp if you don't use --preserve=xattrs, then you might lose your xattrs, including security labels (applies for both SELinux and any LSM using the xattrs)). I would need to setup a small test to remember this. But there should be a way for sure to move the files from temporal location to final one while preserving all attributes, given that rpm has needed privileges (which it does). I wonder if rpm could first unpack all files and dirs to some temp location and then do one FSM commit (if everything went fine) to commit them all one by one. This would solve the problem of how to remove already installed files. > Yup... although some of this could be perhaps dealt with by rearranging the way file permissions etc are laid down: currently they're all done on the final destination, but if the labels, capabilities, modes etc were staged in it would allow dealing with, well, >not all but at least more failure cases. Would likely require quite some changes to fsm, but that's not exactly a bad thing (we've been slowly rewriting the damn thing anyway :) Yes, exactly my though above :) Best Regards, Elena.
0001-Improving-scriptlet-related-rpm-plugin-hooks.patch
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
