Re: [Rpm-maint] Unified set of security hooks for rpm
Sorry: have to resend my last mail again because people from CC again got cut out. I am switching to my gmail address: works much better! Hi, Adding back SELinux guys (wonder why they got stripped in the initial posting: I blame the corporate mail client) :( One question that we have is what is the best way to define a plugin interface for rpm? Should we define just security-related hooks and embed currently existing collection plugin hooks into it or are there any plans for bigger rpm plugin interface that security hooks should be part of? Good question... The current collection hooks aren't really security at all but something else. Yet the selinux policy plugin does kinda fall into that category, and if there's an entirely different plugin type needed for actually putting the security labels (retrieved by eg collection plugin) and such into place, requiring different plugins to interact somehow, and that I suppose would get ugly real fast. There are some other places that could use plugins as well that would fall into entirely different categories. Just as an example, one such thing is translations of i18n header strings from external sources (eg specspo which exists in at least two different flavors, one upstream and one in Fedora) that could be cleanly handled (and would open up new possibilities) with plugins. Yes, I suppose many use cases can benefit of having a genetic rpm plugin interface, but I guess currently the biggest user of such interface is still security (with selinux already being in upstream rpm and us dragging patches around in order to implement our needs). Just FWIW / food for thought, back some time ago I had a brief look at isolating the security activity into a relatively abstract security manager object (instead of plugin hooks littered all around), which could actually be a stack of different bits and pieces implemented by plugins (SELinux/MSS labels, maybe file capabilities etc) but that ran into all sorts of issues right on the first steps already. Whether I just didn't pursue it hard enough or just not a feasible approach I dunno but suspect the latter to be the case. Hm... I think we can make sure that SELinux and our implementation can be pushed to the security manager. Conceptually I don't see the reason why pushing capabilities or other default security attributes (like uid, gids and etc.) to security manager wont' be possible. Could you tell what kind of issues you have run on the first steps? It isn't going to be an easy and simple exercise, but should be possible to do. As for the actual hooks, I think we just need to look at the existing and planned needs of the security labelling etc stuff one by one and try to figure whether it all needs to go into a giant transaction plugin interface or whether it's actually possible to categorize them into tidier sets. I think we have these main group of hooks: - current per-collection hooks - per transaction hooks (pre-tsm, post-tsm) - per package hooks (called in psm): pre-psm, post-psm, verify - per file hooks (called in fsm) + hook for newly created dirs - script hook (called for any invocation of any script (per-transaction/per package)) Would you prefer to break them per group or? I am not sure what you meant with whether it's actually possible to categorize them into tidier sets.? Some other plugin possibility examples: the different rpmio (de)compression types would fit the plugin use-case spot-on. Whether having them as plugins actually makes sense is another question, but it presents some interesting issues: the rpm file io subsystem lives in librpmio, suggesting the core plugin infrastructure should be there as well, instead of librpm itself. However they would need to be able to register themselves into rpmlib() provides which live in librpm, in the transaction layer... The ability for plugins to register custom rpmlib() provides seems generally useful, eg the SELinux/MSSF stuff might want to do it too and I can imagine other cases as well. And the needs of plugins wanting to advertise themselves through rpmlib() provides differ vastly - from very low-level file io to the rather high-level collections and whatnot. The only thing I know for sure is that there are needs (or at least opportunities) for more than one plugin type, and the different types should be able to share the common basic plugin manipulation (loading etc) infrastructure. Yes, that's why I was asking what would be the right way to go currently about the security hooks. I guess it is also can be made step by step: first unify the security hooks and make sure that all security functionality from LSMs are isolated to the plugin. And then integrate security plugin interface to the generic rpm interface. But of course if we can make it right (to the extend it is even possible) from beginning, it is always better. Best Regards, Elena. ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org
Re: [Rpm-maint] Unified set of security hooks for rpm
Hi, Adding back SELinux guys (wonder why they got stripped in the initial posting: I blame the corporate mail client) :( One question that we have is what is the best way to define a plugin interface for rpm? Should we define just security-related hooks and embed currently existing collection plugin hooks into it or are there any plans for bigger rpm plugin interface that security hooks should be part of? Good question... The current collection hooks aren't really security at all but something else. Yet the selinux policy plugin does kinda fall into that category, and if there's an entirely different plugin type needed for actually putting the security labels (retrieved by eg collection plugin) and such into place, requiring different plugins to interact somehow, and that I suppose would get ugly real fast. There are some other places that could use plugins as well that would fall into entirely different categories. Just as an example, one such thing is translations of i18n header strings from external sources (eg specspo which exists in at least two different flavors, one upstream and one in Fedora) that could be cleanly handled (and would open up new possibilities) with plugins. Yes, I suppose many use cases can benefit of having a genetic rpm plugin interface, but I guess currently the biggest user of such interface is still security (with selinux already being in upstream rpm and us dragging patches around in order to implement our needs). Just FWIW / food for thought, back some time ago I had a brief look at isolating the security activity into a relatively abstract security manager object (instead of plugin hooks littered all around), which could actually be a stack of different bits and pieces implemented by plugins (SELinux/MSS labels, maybe file capabilities etc) but that ran into all sorts of issues right on the first steps already. Whether I just didn't pursue it hard enough or just not a feasible approach I dunno but suspect the latter to be the case. Hm... I think we can make sure that SELinux and our implementation can be pushed to the security manager. Conceptually I don't see the reason why pushing capabilities or other default security attributes (like uid, gids and etc.) to security manager wont' be possible. Could you tell what kind of issues you have run on the first steps? It isn't going to be an easy and simple exercise, but should be possible to do. As for the actual hooks, I think we just need to look at the existing and planned needs of the security labelling etc stuff one by one and try to figure whether it all needs to go into a giant transaction plugin interface or whether it's actually possible to categorize them into tidier sets. I think we have these main group of hooks: - current per-collection hooks - per transaction hooks (pre-tsm, post-tsm) - per package hooks (called in psm): pre-psm, post-psm, verify - per file hooks (called in fsm) + hook for newly created dirs - script hook (called for any invocation of any script (per-transaction/per package)) Would you prefer to break them per group or? I am not sure what you meant with whether it's actually possible to categorize them into tidier sets.? Some other plugin possibility examples: the different rpmio (de)compression types would fit the plugin use-case spot-on. Whether having them as plugins actually makes sense is another question, but it presents some interesting issues: the rpm file io subsystem lives in librpmio, suggesting the core plugin infrastructure should be there as well, instead of librpm itself. However they would need to be able to register themselves into rpmlib() provides which live in librpm, in the transaction layer... The ability for plugins to register custom rpmlib() provides seems generally useful, eg the SELinux/MSSF stuff might want to do it too and I can imagine other cases as well. And the needs of plugins wanting to advertise themselves through rpmlib() provides differ vastly - from very low-level file io to the rather high-level collections and whatnot. The only thing I know for sure is that there are needs (or at least opportunities) for more than one plugin type, and the different types should be able to share the common basic plugin manipulation (loading etc) infrastructure. Yes, that's why I was asking what would be the right way to go currently about the security hooks. I guess it is also can be made step by step: first unify the security hooks and make sure that all security functionality from LSMs are isolated to the plugin. And then integrate security plugin interface to the generic rpm interface. But of course if we can make it right (to the extend it is even possible) from beginning, it is always better. 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] Unified set of security hooks for rpm
On 09/14/2012 02:52 PM, Reshetova, Elena wrote: Hi, Hi, I have been writing to the list a while back proposing a set of security hooks that we need for rpm in Tizen. I have discussed with SELinux guys (in CC) and we agreed that can should try to define a unified interface that they can also use. This would allow to move currently partly integrated SELinux code outside of rpm to the security plugin code. Yup. Like said in the past, getting the partly integrated SELinux stuff out of rpm core is something I would love to see. One question that we have is what is the best way to define a plugin interface for rpm? Should we define just security-related hooks and embed currently existing collection plugin hooks into it or are there any plans for bigger rpm plugin interface that security hooks should be part of? Good question... The current collection hooks aren't really security at all but something else. Yet the selinux policy plugin does kinda fall into that category, and if there's an entirely different plugin type needed for actually putting the security labels (retrieved by eg collection plugin) and such into place, requiring different plugins to interact somehow, and that I suppose would get ugly real fast. There are some other places that could use plugins as well that would fall into entirely different categories. Just as an example, one such thing is translations of i18n header strings from external sources (eg specspo which exists in at least two different flavors, one upstream and one in Fedora) that could be cleanly handled (and would open up new possibilities) with plugins. I can start working on the patch to define the combined set of hooks as soon as I am sure I am not going to do smth that is fully unaligned with rpm future plans. Just FWIW / food for thought, back some time ago I had a brief look at isolating the security activity into a relatively abstract security manager object (instead of plugin hooks littered all around), which could actually be a stack of different bits and pieces implemented by plugins (SELinux/MSS labels, maybe file capabilities etc) but that ran into all sorts of issues right on the first steps already. Whether I just didn't pursue it hard enough or just not a feasible approach I dunno but suspect the latter to be the case. As for the actual hooks, I think we just need to look at the existing and planned needs of the security labeling etc stuff one by one and try to figure whether it all needs to go into a giant transaction plugin interface or whether it's actually possible to categorize them into tidier sets. Some other plugin possibility examples: the different rpmio (de)compression types would fit the plugin use-case spot-on. Whether having them as plugins actually makes sense is another question, but it presents some interesting issues: the rpm file io subsystem lives in librpmio, suggesting the core plugin infrastructure should be there as well, instead of librpm itself. However they would need to be able to register themselves into rpmlib() provides which live in librpm, in the transaction layer... The ability for plugins to register custom rpmlib() provides seems generally useful, eg the SELinux/MSSF stuff might want to do it too and I can imagine other cases as well. And the needs of plugins wanting to advertise themselves through rpmlib() provides differ vastly - from very low-level file io to the rather high-level collections and whatnot. The only thing I know for sure is that there are needs (or at least opportunities) for more than one plugin type, and the different types should be able to share the common basic plugin manipulation (loading etc) infrastructure. - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] Unified set of security hooks for rpm
Hi, I have been writing to the list a while back proposing a set of security hooks that we need for rpm in Tizen. I have discussed with SELinux guys (in CC) and we agreed that can should try to define a unified interface that they can also use. This would allow to move currently partly integrated SELinux code outside of rpm to the security plugin code. One question that we have is what is the best way to define a plugin interface for rpm? Should we define just security-related hooks and embed currently existing collection plugin hooks into it or are there any plans for bigger rpm plugin interface that security hooks should be part of? I can start working on the patch to define the combined set of hooks as soon as I am sure I am not going to do smth that is fully unaligned with rpm future plans. 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
