SELinux and RPM packages

[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 at 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.