Bug 1472786

Summary: Failed yum transaction when updating packages via OSAD with SELinux enforcing
Product: Red Hat Enterprise Linux 7 Reporter: Frantisek Kobzik <fkobzik>
Component: selinux-policyAssignee: Lukas Vrabec <lvrabec>
Status: CLOSED WONTFIX QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: cww, jhutar, ktordeur, lvrabec, mgrepl, mmalik, plautrba, pvrabec, ssekidde
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-26 13:36:59 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: 1477664    
Attachments:
Description Flags
audit.log none

Description Frantisek Kobzik 2017-07-19 12:09:33 UTC
Created attachment 1301053 [details]
audit.log

Description of problem:
Performing update of certain packages (see below) on a RHEL machine via Spacewalk with OSAD enabled results in failed yum transaction. Some of the update packages are duplicated after the operation (both the new and old version is installed on the system).
Moreover, a lot of SELinux denials related to osad_t are reported in the /var/log/audit/audit.log.

Setting SELinux to permissive "resolves" the issue (no failed transaction, no duplicate packages).

Not using OSAD, but performing updates via rhnsd daemon works fine (even with SELinux=enforcing).

Version-Release number of related components:
osad-5.11.80.2-24.2.noarch
selinux-policy/selinux-policy-targeted 3.12.1-153.el7.noarch

How reproducible:
Deterministic.

Steps to Reproduce:
1. Register a RHEL 7.0 machine in spacewalk.
2. Enable OSAD on it,
3. Make sure SELinux=enforcing, and that selinux-policy-3.12.1-153 and related packages are installed.
4. Schedule an update of selinux-policy package (in my case I was upgrading to 3.13.1-102.el7_3).
5. Wait until the action is completed.

Actual results:
- Yum transaction fails,
- there are duplicate packages on the system,
- /var/log/audit/audit.log contains a lot of denials for osad_t.

Output of 'yum history list':
ID | Login user    |Date and time    | Action(s)| Altered
------------------ --------------------------------------
5  | System <unset>|2017-07-19 10:51 | Update   | 22 **

Output of 'package-cleanup --dupes':
kmod-20-9.el7.x86_64
kmod-14-9.el7.x86_64
systemd-219-30.el7_3.9.x86_64
systemd-208-11.el7.x86_64
selinux-policy-3.12.1-153.el7.noarch
selinux-policy-3.13.1-102.el7_3.16.noarch
libselinux-2.2.2-6.el7.x86_64
libselinux-2.5-6.el7.x86_64
systemd-libs-219-30.el7_3.9.x86_64
systemd-libs-208-11.el7.x86_64
setools-libs-3.3.7-46.el7.x86_64
setools-libs-3.3.8-1.1.el7.x86_64
policycoreutils-python-2.5-11.el7_3.x86_64
policycoreutils-python-2.2.5-11.el7.x86_64
libselinux-utils-2.2.2-6.el7.x86_64
libselinux-utils-2.5-6.el7.x86_64
policycoreutils-2.5-11.el7_3.x86_64
policycoreutils-2.2.5-11.el7.x86_64
libselinux-python-2.5-6.el7.x86_64
libselinux-python-2.2.2-6.el7.x86_64
libsepol-2.1.9-3.el7.x86_64
libsepol-2.5-6.el7.x86_64
libsemanage-2.5-5.1.el7_3.x86_64
libsemanage-2.1.10-16.el7.x86_64
dracut-033-161.el7.x86_64
dracut-033-463.el7_3.2.x86_64
glib2-2.36.3-5.el7.x86_64
glib2-2.46.2-4.el7.x86_64
libsemanage-python-2.1.10-16.el7.x86_64
libsemanage-python-2.5-5.1.el7_3.x86_64
policycoreutils-devel-2.5-11.el7_3.x86_64
policycoreutils-devel-2.2.5-11.el7.x86_64
selinux-policy-targeted-3.12.1-153.el7.noarch
selinux-policy-targeted-3.13.1-102.el7_3.16.noarch

Expected results:
yum transaction succeeds, there are no package duplicates on the system

Additional info:
Attaching audit.log.

It seems SELinux is restricting OSAD in this case, that's why I opened the bug against selinux-policy - please correct me if I'm wrong.

Comment 14 Red Hat Bugzilla Rules Engine 2018-04-26 13:36:59 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

Comment 15 Lukas Vrabec 2018-04-26 14:04:45 UTC
Frantisek,

We're not able to reproduce your issue, we're closing this ticket. Feel free to  re-oppen it if you still facing this issue. 

Lukas.