Bug 1472786 - Failed yum transaction when updating packages via OSAD with SELinux enforcing
Failed yum transaction when updating packages via OSAD with SELinux enforcing
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy (Show other bugs)
7.0
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Lukas Vrabec
Milos Malik
:
Depends On:
Blocks: 1477664
  Show dependency treegraph
 
Reported: 2017-07-19 08:09 EDT by Frantisek Kobzik
Modified: 2018-04-26 10:04 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-04-26 09:36:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
audit.log (533.99 KB, text/plain)
2017-07-19 08:09 EDT, Frantisek Kobzik
no flags Details

  None (edit)
Description Frantisek Kobzik 2017-07-19 08:09:33 EDT
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 09:36:59 EDT
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Comment 15 Lukas Vrabec 2018-04-26 10:04:45 EDT
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.

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