SELinux and RPM packages

[Dmitry Makovey]

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?

-- 
Dmitry Makovey
Web Systems Administrator
Athabasca University
[phone]
---
Confidence is what you have before you understand the problem
    Woody Allen

When in trouble when in doubt run in circles scream and shout 
     http://www.wordwizard.com/phpbb3/viewtopic.php?f=16&t=19330

[Dominick Grift]

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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[mark]

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

[Dmitry Makovey]

I'll just reply to both Dominick and mark below in one swift shot:

On February 2, 2012 15:19:15 m.roth(a)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" 

-- 
Dmitry Makovey
Web Systems Administrator
Athabasca University
[phone]
---
Confidence is what you have before you understand the problem
    Woody Allen

When in trouble when in doubt run in circles scream and shout 
     http://www.wordwizard.com/phpbb3/viewtopic.php?f=16&t=19330

[Paul Howarth]

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(a)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.

[Dmitry Makovey]

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)

-- 
Dmitry Makovey
Web Systems Administrator
Athabasca University
[phone]
---
Confidence is what you have before you understand the problem
    Woody Allen

When in trouble when in doubt run in circles scream and shout 
     http://www.wordwizard.com/phpbb3/viewtopic.php?f=16&t=19330

[Joe Nall]

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

[Robert Nichols]

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?

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

[Dmitry Makovey]

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. 

-- 
Dmitry Makovey
Web Systems Administrator
Athabasca University
[phone]
---
Confidence is what you have before you understand the problem
    Woody Allen

When in trouble when in doubt run in circles scream and shout 
     http://www.wordwizard.com/phpbb3/viewtopic.php?f=16&t=19330