Red Hat Bugzilla – Bug 840679
Removal of SELinux policy modules for software not delivered by RHEL
Last modified: 2012-10-09 08:34:00 EDT
Description of problem, actual and expected results:
I would like to suggest the removal of all SELinux policy modules for
software and programs that are not delivered by RHEL. Background is,
that (at least from my point of view) the Red Hat Support team nicely
explains each time that $software is not part of RHEL and thus it's not
supported (or similar). However, the root cause is the partially really
outdated and/or incomplete RHEL SELinux policy; at least when comparing
to Fedora. Additionally updates usually only take place with a new minor
release, thus usually about only every six months, but not with FasTrack
like each week or so.
If the SELinux policy would be handled more flexible regarding to RPM
packaging, RHEL could only ship these few less modules for RHEL itself.
The rest, like amavisd-new, clamav and friends could make it into via
Fedora EPEL for example. Right now, clamav and amavisd-new are covered
by the RHEL SELinux policy and eg. need one or the other backport from
Fedora as it seems. This is also a proposal for RHEL 7.
Version-Release number of selected component (if applicable):
Cross-filed case 00678456 in the Red Hat Customer Portal.
I disagree, removing the policy will not solve the problem, since a confined application that we do ship like apache will need to interact with the domains. I guess we could move to shipping policies that are unconfined for third party products.
In your example of clamav and amavisd, these apps interact with all of our mailers, postfix, other spam filters excetera, Removing the policy will not solve the problem of handling these interactions.
If I get you right, the SELinux policy is currently not that modular anymore?
My thought was, that everything for clamav would be in it's own module which
can be installed from EPEL, too. Right now, the clamav SELinux policy module
is part of RHEL, while clamav is only in EPEL, not in RHEL. Couldn't this be
more fine splitted?
Well the policy is still modular. You should be able to disable non-base modules (most of them) => policy is modular
If you disable/remove a module, a service will run as initrc_t for example. But if a daemon with a domain needs to talk with this service which is now initrc_t, you will see AVC msgs.
Why does RHEL ship policy modules for software it does not ship? Would it not
make more sense to ship each policy module which each software? Like Postfix
ships the SELinux policy module for postfix. Means the clamav policy module is
in that case from EPEL, because clamav is from EPEL, too. Means, I would not
to mess up with the support team claiming that clamav is not supported by RHEL
clamav or any other package is welcome to ship policy with their package. Several packages have attempted to do this in the past, but most have asked us to take over management of them, because the owners do not understand how policy works or it becomes easier as interaction between different domains, can cause problems.
If you want to add policy to clamav to fix the problem and now wait for the next rhel update to fix, you are welcome to do so.
We have always shipped policy for domains not shipped with Red Hat since we see interaction between domains that we do ship, like a confined domain interacting with a virus detector application.
I dislike the current situation, because SELinux policy updates in RHEL are
just slow. Most of them are delayed till the next RHEL minor release simply,
which for example also applied and applies to nearly all of my open tickets/
reports. Opening tickets in the Red Hat Customer Portal does not speed up...
Case 00695178 is a good example that the inclusion of SELinux policy modules
for software that you don't ship sucks. Now somebody is evaluating if a clamav
SELinux policy update can or will be included for the next SELinux package.
And if we did not have this, it would suck more, because all of the mail programs and other tools that are plugged into clamav would break.
We release preliminary polcies on http://people.redhat.com/dwalsh/SELinux/RHEL6
And I have no problems pushing policy out quicker if people believe this is a good idea.