Bug 875543

Summary:	/distribution/install reports AVC denials differently than normal tasks
Product:	[Retired] Beaker	Reporter:	Dan Callaghan <dcallagh>
Component:	tests	Assignee:	beaker-dev-list
Status:	CLOSED EOL	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	0.9	CC:	amahdal, azelinka, mastyk, omoris, tools-bugs
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	SELinux
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	859365	Environment:
Last Closed:	2020-03-24 08:13:57 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:

Description Dan Callaghan 2012-11-12 01:13:47 UTC

+++ This bug was initially created as a clone of Bug #859365 +++

> A failure in /distribution/install does not mean the installation itself has
> failed (in that case the recipe will probably never start, or fail in some
> other weird way) but rather that post-install checks have failed. In the
> case of J:300537, J:300659, J:300718 it failed due to this AVC denial:
> 
> ******** SElinux AVC Failures ********
> [   54.234759] type=1400 audit(1348048560.060:4): avc:  denied  { create }
> for  pid=800 comm="systemd-tmpfile" name="user"
> scontext=system_u:system_r:systemd_tmpfiles_t:s0
> tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir
> 
> which seems like a bug in the selinux policy.

I understand that the task isn't the installation itself but it still is confusing. I believe that these post-install checks should only produce FAIL result if the job is likely to fail (e.g. some part of harness is missing). AVC denial during installation? WARN is enough.

Or if it is on par with other tasks, just use the same mechanism - inject the /avc result in it. That would make it fail but fail in a consistent way with other tasks.

Comment 2 Dan Callaghan 2014-03-18 22:01:34 UTC

*** Bug 1077203 has been marked as a duplicate of this bug. ***

Comment 3 Dan Callaghan 2018-07-19 06:21:24 UTC

In bug 1188539 I am looking at a fresh implementation of the /distribution/install task (new version to be called /distribution/check-install) and I am trying to avoid having any AVC checking or dmesg checking logic in the new implementation of the task.

In my investigations on that bug, it seems to me the only situation where /distribution/install *would* find an AVC denial and report it under its Sysinfo result and the harness *wouldn't* find it, is if the denial happened on boot-up before auditd started and thus it went to kernel messages instead.

Thus I propose:

* we consider this WONTFIX for the existing /distribution/install implementation, which we will eventually phase out

* this issue won't be applicable for the new /distribution/check-install implementation, because it won't do any AVC checking itself

* we turn this bug into an RFE for the harness AVC checking, to make it find denials which appear in dmesg but not audit.log