Re: [Rpm-maint] [PATCH 1/2] Extending rpm plugin interface, part 1
On 11/08/2012 01:01 PM, Reshetova, Elena wrote: Okay then, done and pushed. Now that I looked closer, I spotted (and fixed) a couple of more issues: a tiny memleak from early rpmtsSetupTransactionPlugins() return and some further cosmetics (two soft-tabs instead of one hard-tab, trailing whitespace etc), but nothing dramatic. Thank you! I will seriously try to improve my style. I am not using vim for code edits, but I think I should probably reconsider it or get some kind of editor that shows all symbols explicitly. Pain to read but I get it right at the end :) If you dont otherwise use vim, might be easier to figure out how to configure your preferred editor to honor the rpm style - since its essentially just KR I'd assume pretty much any coding-oriented editor can deal with that. Vi(m) is a fairly strange beast initially :) Oh and one other thing I noticed just now that'll need further thought: currently the script setup hook only runs for external scripts, but not the embedded Lua-scripts. Which are getting more and more common... They'll obviously need to be handled quite differently as they run within the rpm process itself, ie fork() + exec() does not occur. Yes, I don't currently have a very good idea how this case should be handled. The idea of script hook is that it sets the needed security context, but we obviously can't do this for lua case unless we want to drop the whole rpm security context. As a temporal and draconic measure we can compile rpm without lua support to close this hole, but it is no-go in the future since it is getting more and more usage. I guess this is one of the things that I need to think more about. In case of SELinux, AFAICS a process can change its own context back and forth, IF permitted by the policy. So at least in theory it should possible to switch to a different context while executing a scriptlet and then switch back to the original context. Perhaps the script hook should just follow the common pre/post-hook pattern of the other hooks afterall: pre-hook would just replace the current setup hook, and post-hook would run after the script got executed. If we add an extra argument to notify the hooks whether it's an internal or external script (or a more generic flags argument to allow passing more such bits later), the plugin(s) should be able to figure out what to do about it. - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH 1/2] Extending rpm plugin interface, part 1
Oh and one other thing I noticed just now that'll need further thought: currently the script setup hook only runs for external scripts, but not the embedded Lua-scripts. Which are getting more and more common... They'll obviously need to be handled quite differently as they run within the rpm process itself, ie fork() + exec() does not occur. Yes, I don't currently have a very good idea how this case should be handled. The idea of script hook is that it sets the needed security context, but we obviously can't do this for lua case unless we want to drop the whole rpm security context. As a temporal and draconic measure we can compile rpm without lua support to close this hole, but it is no-go in the future since it is getting more and more usage. I guess this is one of the things that I need to think more about. In case of SELinux, AFAICS a process can change its own context back and forth, IF permitted by the policy. So at least in theory it should possible to switch to a different context while executing a scriptlet and then switch back to the original context. It isn't so easy for Smack for example (and for a good reason) and I believe SELinux won't use this functionality for this kind of purpose. A process can change its security context in Smack, if it has CAP_MAC_ADMIN, so rpm (a trusted process) can have this cap and then drop the credentials when running lua script from untrusted package. However, we also want to drop CAP_MAC_ADMIN (and all the rest of sensitive caps) for such lua script (otherwise it can setup whatever context it wants for itself), and after such drop, and after lua script execution is done, rpm can't get its own security context back (because CAP_MAC_ADMIN is lost). This actually makes sense since once you run untrusted code in the same process space you can't really guarantee that you can safely come back and run (in the same process) a trusted code with high privileges. Same logic would apply if we don't speak about LSMs, but traditional Linux DAC. Rpm usually runs as root with all POSIX caps, but suppose we want to drop the sensitive caps while running untrusted lua scripts or even simply run them under different uid/gid. How do we do this with lua scripts currently? Perhaps the script hook should just follow the common pre/post-hook pattern of the other hooks afterall: pre-hook would just replace the current setup hook, and post-hook would run after the script got executed. If we add an extra argument to notify the hooks whether it's an internal or external script (or a more generic flags argument to allow passing more such bits later), the plugin(s) should be able to figure out what to do about it. This would be good, if we can indeed manipulate the context freely, but because of above we really can't. Best Regards, Elena. smime.p7s Description: S/MIME cryptographic signature ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH 1/2] Extending rpm plugin interface, part 1
On 11/09/2012 02:27 PM, Reshetova, Elena wrote: Oh and one other thing I noticed just now that'll need further thought: currently the script setup hook only runs for external scripts, but not the embedded Lua-scripts. Which are getting more and more common... They'll obviously need to be handled quite differently as they run within the rpm process itself, ie fork() + exec() does not occur. Yes, I don't currently have a very good idea how this case should be handled. The idea of script hook is that it sets the needed security context, but we obviously can't do this for lua case unless we want to drop the whole rpm security context. As a temporal and draconic measure we can compile rpm without lua support to close this hole, but it is no-go in the future since it is getting more and more usage. I guess this is one of the things that I need to think more about. In case of SELinux, AFAICS a process can change its own context back and forth, IF permitted by the policy. So at least in theory it should possible to switch to a different context while executing a scriptlet and then switch back to the original context. It isn't so easy for Smack for example (and for a good reason) and I believe SELinux won't use this functionality for this kind of purpose. Note in theory in the above :) libselinux has an API for it, I dont know if there's anything that's actually allowed to flip the context back and forth: /* Set the current security context to con. Note that use of this function requires that the entire application be trusted to maintain any desired separation between the old and new security contexts, unlike exec-based transitions performed via setexeccon. When possible, decompose your application and use setexeccon()+execve() instead. Note that the application may lose access to its open descriptors as a result of a setcon() unless policy allows it to use descriptors opened by the old context. */ extern int setcon(const security_context_t con); extern int setcon_raw(const security_context_t con); A process can change its security context in Smack, if it has CAP_MAC_ADMIN, so rpm (a trusted process) can have this cap and then drop the credentials when running lua script from untrusted package. However, we also want to drop CAP_MAC_ADMIN (and all the rest of sensitive caps) for such lua script (otherwise it can setup whatever context it wants for itself), and after such drop, and after lua script execution is done, rpm can't get its own security context back (because CAP_MAC_ADMIN is lost). This actually makes sense since once you run untrusted code in the same process space you can't really guarantee that you can safely come back and run (in the same process) a trusted code with high privileges. Same logic would apply if we don't speak about LSMs, but traditional Linux DAC. Rpm usually runs as root with all POSIX caps, but suppose we want to drop the sensitive caps while running untrusted lua scripts or even simply run them under different uid/gid. How do we do this with lua scripts currently? Scripts run with all the powers that rpm itself has, and there's not a whole lot that can be done about it: scriptlets expect to, and often need to, do all sorts of crazy things. The differences from regular exec()'ed scripts and Lua-ones are basically: - As Lua scripts run in the rpm process space, some extra protection is needed, like saving + restoring current working directory, umask and preventing Lua scriptlet from exec()'ing or exit()'ing the process. - There are no context switches for Lua scripts in SELinux world currently: Lua scripts run with rpm_exec_t context, regular scripts run with rpm_script_t. But both are practically omnipotent contexts, because they have to be. Perhaps the script hook should just follow the common pre/post-hook pattern of the other hooks afterall: pre-hook would just replace the current setup hook, and post-hook would run after the script got executed. If we add an extra argument to notify the hooks whether it's an internal or external script (or a more generic flags argument to allow passing more such bits later), the plugin(s) should be able to figure out what to do about it. This would be good, if we can indeed manipulate the context freely, but because of above we really can't. Oh, I meant the common pre- and post-hook pattern seems like it would make sense for scripts too in any case, regardless of whether it helps solving the context issue. It *might* in the SELinux case, but a post-hook could have some other entirely different uses, and it'd make the whole thing a bit more symmetric :) - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
