Bug 840679

Summary:	Removal of SELinux policy modules for software not delivered by RHEL
Product:	Red Hat Enterprise Linux 6	Reporter:	Robert Scheck <redhat-bugzilla>
Component:	selinux-policy	Assignee:	Miroslav Grepl <mgrepl>
Status:	CLOSED NOTABUG	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.3	CC:	dwalsh, mmalik
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-10-09 12:34:00 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	782183

Description Robert Scheck 2012-07-16 21:49:55 UTC

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):
selinux-policy-3.7.19-155.el6_3.noarch

Comment 1 Robert Scheck 2012-07-16 21:56:27 UTC

Cross-filed case 00678456 in the Red Hat Customer Portal.

Comment 3 Daniel Walsh 2012-07-17 15:20:34 UTC

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.

Comment 4 Robert Scheck 2012-07-17 15:28:27 UTC

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?

Comment 5 Miroslav Grepl 2012-07-18 10:37:08 UTC

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.

Comment 6 Robert Scheck 2012-07-18 10:42:12 UTC

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
for example.

Comment 7 Daniel Walsh 2012-07-23 15:29:32 UTC

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.

Comment 8 Robert Scheck 2012-08-08 09:02:58 UTC

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

Comment 9 Robert Scheck 2012-08-22 12:04:06 UTC

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.

Comment 10 Daniel Walsh 2012-09-17 16:41:56 UTC

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.

Comment 11 Daniel Walsh 2012-09-17 16:43:17 UTC

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.