Hi list,
I know I have asked that question before and the answer was to use "semanage/setsebool" from %post section.
However here's my dilemma:
say I have packageA and packageB, both running some "semanage/setsebool" combinations that overlap (most likely case for the setsebool). If I mirror statements in %post into the %postun whenever I uninstall packageA I will be wiping settings needed by packageB. How are people dealing with those? It doesn't look like Fedora/RedHat has some strict policy or guideline on that (or do they? did I miss it?) so I am interested how are others coping with this? Falling back to manual process? Some extra scripting?
On Thu, 2012-02-02 at 12:42 -0700, Dmitry Makovey wrote:
Hi list,
I know I have asked that question before and the answer was to use "semanage/setsebool" from %post section.
I am curious: what type of stuff are you referring to when you mention semanage?
As for setsebool i do not see a problem with conflicts/overlap. If you just add 'setsebool -P somebool on' in your %post if you need it to be on then i dont see how it matters what the current value of the boolean is.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Dominick Grift wrote:
On Thu, 2012-02-02 at 12:42 -0700, Dmitry Makovey wrote:
Hi list,
I know I have asked that question before and the answer was to use "semanage/setsebool" from %post section.
I am curious: what type of stuff are you referring to when you mention semanage?
As for setsebool i do not see a problem with conflicts/overlap. If you just add 'setsebool -P somebool on' in your %post if you need it to be on then i dont see how it matters what the current value of the boolean is.
For that matter, if packageA needs a boolean on, and packageB needs it off, you have deeper problems that you're going to have to resolve before you think of building packages.
mark
I'll just reply to both Dominick and mark below in one swift shot:
On February 2, 2012 15:19:15 m.roth@5-cent.us wrote:
I am curious: what type of stuff are you referring to when you mention semanage?
packageA:
%post semanage fcontext -a -t httpd_sys_content_t /webapps/appA setsebool -P httpd_can_sendmail on
pacakgeB:
%post semanage fcontext -a -t httpd_sys_content_t /srv/appB setsebool -P httpd_can_sendmail on
above is a sample that is not exact, but presents situation. In both cases I would want to clean-up after package is uninstalled to get system into the previous state:
packageA
%postun
restorecon -R -v /webapps/appA setsebool -P httpd_can_sendmail off
And I just "shot" packageB's requirement. Same can happen to the fcontext stuff, just oversimplifying here. I do not feel like building meta-packages for each statement and add dependancies, like:
httpd-sendmail-trigger.rpm:
%post setsebool -P httpd_can_sendmail off
and make packageA and packageB:
Require: httpd-sendmail-trigger
with a bit more added complexity it's going to be hairy maintaining all the interdependancies etc.
As for setsebool i do not see a problem with conflicts/overlap. If you just add 'setsebool -P somebool on' in your %post if you need it to be on then i dont see how it matters what the current value of the boolean is.
For that matter, if packageA needs a boolean on, and packageB needs it off, you have deeper problems that you're going to have to resolve before you think of building packages.
see above, it's not about install time - install is actually no-problem. It's the removal, upgrade when you need to relabel etc. Above is a very simplistic scenario, you can add complexities like upgraded package been moved to a different directory, while previous semanage rules overlapped on the old one, now removing packageA would wipe all the fcontext goodness it installed there to begin with. Kind of messy, unless I'm missing something either in RPM or SELinux.
My current way of thinking is: build module-like infrastructure:
/etc _selinux.d _packageA _policy1.sh _packageB _policy1.sh _policy2.sh
then do something like:
$ (find /etc/selinux.d/ -type f -exec cat {} ; | sort -u | sh
in which case we run above whenever package is installed/remove/updated (and subsequently structure of the above /etc/selinux.d has changed), but we need to first: remove all existing customizations (fcontext, booleans, etc) before launch, second: relabel everything right after - because there are going to be leftovers from the old packages.
Problem with the above - system is going to be "broken" while relabeling and reinstall of policies is happening. And those are not really fast processes. Not to mention that it seems a bit "clunky" and "kludgy"
On 02/02/2012 10:45 PM, Dmitry Makovey wrote:
I'll just reply to both Dominick and mark below in one swift shot:
On February 2, 2012 15:19:15 m.roth@5-cent.us wrote:
I am curious: what type of stuff are you referring to when you mention semanage?
packageA:
%post semanage fcontext -a -t httpd_sys_content_t /webapps/appA setsebool -P httpd_can_sendmail on
pacakgeB:
%post semanage fcontext -a -t httpd_sys_content_t /srv/appB setsebool -P httpd_can_sendmail on
above is a sample that is not exact, but presents situation. In both cases I would want to clean-up after package is uninstalled to get system into the previous state:
packageA
%postun
restorecon -R -v /webapps/appA setsebool -P httpd_can_sendmail off
And I just "shot" packageB's requirement. Same can happen to the fcontext stuff, just oversimplifying here. I do not feel like building meta-packages for each statement and add dependancies, like:
httpd-sendmail-trigger.rpm:
%post setsebool -P httpd_can_sendmail off
and make packageA and packageB:
Require: httpd-sendmail-trigger
with a bit more added complexity it's going to be hairy maintaining all the interdependancies etc.
As for setsebool i do not see a problem with conflicts/overlap. If you just add 'setsebool -P somebool on' in your %post if you need it to be on then i dont see how it matters what the current value of the boolean is.
For that matter, if packageA needs a boolean on, and packageB needs it off, you have deeper problems that you're going to have to resolve before you think of building packages.
see above, it's not about install time - install is actually no-problem. It's the removal, upgrade when you need to relabel etc. Above is a very simplistic scenario, you can add complexities like upgraded package been moved to a different directory, while previous semanage rules overlapped on the old one, now removing packageA would wipe all the fcontext goodness it installed there to begin with. Kind of messy, unless I'm missing something either in RPM or SELinux.
My current way of thinking is: build module-like infrastructure:
/etc _selinux.d _packageA _policy1.sh _packageB _policy1.sh _policy2.sh
then do something like:
$ (find /etc/selinux.d/ -type f -exec cat {} ; | sort -u | sh
in which case we run above whenever package is installed/remove/updated (and subsequently structure of the above /etc/selinux.d has changed), but we need to first: remove all existing customizations (fcontext, booleans, etc) before launch, second: relabel everything right after - because there are going to be leftovers from the old packages.
Problem with the above - system is going to be "broken" while relabeling and reinstall of policies is happening. And those are not really fast processes. Not to mention that it seems a bit "clunky" and "kludgy"
You could actually include pre-built modules with the necessary policy in your packages, e.g. as described in:
http://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft
So if package A and package B both have policy allowing something (rather than messing with a boolean), removing one of those packages and its policy module will still leave the other's policy module present and hence it will still be able to do what it needed to do.
Paul.
On February 3, 2012 09:41:07 Paul Howarth wrote:
You could actually include pre-built modules with the necessary policy in your packages, e.g. as described in:
http://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft
didn't notice that document before - thanks for the reference.
So if package A and package B both have policy allowing something (rather than messing with a boolean), removing one of those packages and its policy module will still leave the other's policy module present and hence it will still be able to do what it needed to do.
In other words - I did suspect that modules is the closest thing that complies with the above (aside from meta-packages that only have %post sections populated with "semanage" statements)
On Feb 2, 2012, at 1:42 PM, Dmitry Makovey wrote:
Hi list,
I know I have asked that question before and the answer was to use "semanage/setsebool" from %post section.
However here's my dilemma:
say I have packageA and packageB, both running some "semanage/setsebool" combinations that overlap (most likely case for the setsebool). If I mirror statements in %post into the %postun whenever I uninstall packageA I will be wiping settings needed by packageB. How are people dealing with those? It doesn't look like Fedora/RedHat has some strict policy or guideline on that (or do they? did I miss it?) so I am interested how are others coping with this? Falling back to manual process? Some extra scripting?
rpm triggers
http://rpm.org/api/4.4.2.2/triggers.html
joe
On 02/02/2012 01:42 PM, Dmitry Makovey wrote:
Hi list,
I know I have asked that question before and the answer was to use "semanage/setsebool" from %post section.
However here's my dilemma:
say I have packageA and packageB, both running some "semanage/setsebool" combinations that overlap (most likely case for the setsebool). If I mirror statements in %post into the %postun whenever I uninstall packageA I will be wiping settings needed by packageB. How are people dealing with those? It doesn't look like Fedora/RedHat has some strict policy or guideline on that (or do they? did I miss it?) so I am interested how are others coping with this? Falling back to manual process? Some extra scripting?
Even if you uninstall both packageA and packageB, how can you be sure that said boolean was not set prior to the installation of either of those packages, and is still required by something else installed on the system?
On February 3, 2012 13:51:46 Robert Nichols wrote:
Even if you uninstall both packageA and packageB, how can you be sure that said boolean was not set prior to the installation of either of those packages, and is still required by something else installed on the system?
Yep, boolean present a challange since you can't incorporate them into the policy modules like the rest. So no matter how you slice it booleans remain an "unknown" value which needs to be tracked manually.
selinux@lists.fedoraproject.org
-
Dmitry Makovey -
Dominick Grift -
Joe Nall -
mark -
Paul Howarth -
Robert Nichols