Hi, >Obviously there needs to be some way of loading the plugins... What kinda >bothers me here is the notion of "security plugin" - except for perhaps the >signature/conflict hooks, there's nothing inherently security-specific here. >The two immediate candidates *are* security-oriented, but they're very, very >different in what they do and how they affect the system. Eg if you disable >SELinux labeling on a system where SELinux is enabled, you'll pretty much >just shoot yourself in the foot (by ending up with a rather screwed up >system) >rather than fundametally bypass system security. >"Transaction plugin" or something to that effect would seem to be more >appropriate as these hooks could be used for all sorts of purposes >(additional logging / interaction with other systems like dbus notifications >for somebody ... whatever). Ok, let's call it indeed a "transaction plugin" because security plugin can be considered as a particular case of transaction plugin. I will rename it. >The script setup hook is fairly obvious too, just forgot to mention it. >The one question with that is (again) the argument(s) it receives: >currently its ARGV_t, but does it actually need the entire argv or would just >the actual executable path suffice for the setup? I am fine with just the path, but looking to SELinux code, the rpm_execcon() func needs the whole argv struct. @ Stephen, do you know how mandatory for SELinux is to have the whole argv struct? Is it just because of rpm_execcon() API or? >Another possibility might be passing an rpmScript "object" (which would need >exporting and probably added interfaces, but that's kinda in the plans anyway >at some point). But perhaps that's best left for later. Yes, I guess there is always a possibility to change these things when better objects/structs are available. I am quite sure I can make these changes later since I will be responsible for introducing these hooks at the first place :) I don't just plan to dump this on you once and go away! >I dunno... There are soooo many different options and API flags that affect >these things, attempting to enforce things from the inside of rpm seems >hopelessly futile: practically every aspect of rpm's behavior is overridable >via cli, API and configuration. Including the paths where rpm loads its >configuration >from. You'd need to have a hard-wired list of mandatory >plugins and theirr non-macro paths compiled rpm to enforce anything at all. >And even then, if you have cli access as root, what's to prevent the user >from just replacing the executable/libraries with something that doesn't >enforce anything? We can prevent user or malicious app from modifying the rpm itself, its plugins, configuration files by using the MAC (as selinux or smack) in run-time and integrity protection (as IMA/EVM) for offline protection. Using librpm directly by user or program actually should be quite safe, because user or malicious app won't get any powerful permissions in the most restrictive setup (no classical root, no posix capabilities). There normally would be some higher level package manager on top of rpm that would have needed permissions and would execute rpm (which would inherit the permissions in this case) with a proper set of cli arguments and environment. If everything goes well, then we don't need to worry that rpm would install smth without a plugin being run. But what if the system gets damaged somehow (not even necessary attacked) and plugin binary happen to disappear? In this case given that we are relying on additional checks for the plugin, it is a very bad idea to proceed without it. It would indeed make the whole system unsecure and in addition also unusable, and this is all even without user understanding that system got corrupted. So, this was the idea behind having this "plugin present" check and stop if failed in place. I was looking at it as some kind of analogy to sysinit that can make checks during the boot process that needed services (example from security: device lock daemon) are up and if they aren't up, then it can stop the boot and actually go to some recovery mode. Does this explanation makes a bit more sense? >Yes, its indeed what the MSM hook does, rather than the hook itself, that >bothers me. And more generally, the fact that such things become possible >with plugins. I guess its not possible to really prevent, given sufficiently >powerful plugin interface, but if nothing else the interfaces should >encourage the >"correct" usage and discourage working behind rpms back. >Whatever that means - I do realize I'm just waving hands again :) >> I am quite sure I can change it in the plugin itself. >Ok, that'd be good. I was actually wondering why its done the way it is now - >if there is an actual reason (such insufficient information available at that >point), I'd like to understand it. My understanding before was that in the current implementation you are able to skip the installation of conflicting files without failing the whole package, but now when I think of this it doesn't seem like a right thing to do. I have "inherited" these hooks from Tero (in CC now) and while I have done quite some changes to them (some I actually still need to sync to open repo that you get to see them too), I haven't touched the conflict hook at all. @Tero, do you still remember the reason why the conflict hook was done in this way? Why wasn't it better to check the conflicts before the transaction and fail the whole transaction if conflicts are seen? Best Regards, Elena.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
