Bug 875543 - /distribution/install reports AVC denials differently than normal tasks
Summary: /distribution/install reports AVC denials differently than normal tasks
Keywords:
Status: CLOSED EOL
Alias: None
Product: Beaker
Classification: Retired
Component: tests
Version: 0.9
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact:
URL:
Whiteboard: SELinux
: 1077203 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-12 01:13 UTC by Dan Callaghan
Modified: 2020-03-24 08:14 UTC (History)
5 users (show)

Fixed In Version:
Clone Of: 859365
Environment:
Last Closed: 2020-03-24 08:13:57 UTC
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.