RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2111410 - RHVH 4.5.2: There are AVC denied errors (setfiles) in audit.log after upgrade
Summary: RHVH 4.5.2: There are AVC denied errors (setfiles) in audit.log after upgrade
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.6
Hardware: Unspecified
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Zdenek Pytela
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On: 1955415 1955461 1955466 2020997 2063871 2082147 2095184
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-07-27 09:37 UTC by cshao
Modified: 2022-11-08 12:59 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of: 2020997
Environment:
Last Closed: 2022-08-11 14:55:46 UTC
Type: ---
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-129337 0 None None None 2022-07-28 02:02:51 UTC

Comment 2 Nikolai Sednev 2022-07-27 11:26:31 UTC 
Is this RHVH authentic bug?
Comment 6 Zdenek Pytela 2022-08-01 14:29:54 UTC 
As momd seems to be the service, can you try

  # chcon -t virtd_exec_t /usr/sbin/momd

and reproduce again? This change will persist reboot, but not reinstallation.
Comment 10 Michal Skrivanek 2022-08-03 12:00:19 UTC 
(In reply to Zdenek Pytela from comment #6)
> As momd seems to be the service, can you try
> 
>   # chcon -t virtd_exec_t /usr/sbin/momd
> 
> and reproduce again? This change will persist reboot, but not reinstallation.

why momd?
I don't see a reason why momd or ovirt-imageio or ovirt-ha-* would ever talk to lldpad.

FWIW this is a result on rhvh-4.5.2.1-0.20220802.0 with selinux-policy-3.14.3-95.el8_6.2.noarch in our dev test env. This is fresh installation of HE-eanabled host(hence ovirt-hosted-engine-ha stuff), not an upgrade.
system_u:system_r:unconfined_service_t:s0 ovirtimg 26094 1  0 08:55 ?      00:00:01 /usr/bin/python3 -s /usr/bin/ovirt-imageio
system_u:system_r:unconfined_service_t:s0 openvsw+ 31006 1  0 08:56 ?      00:00:00 ovn-controller unix:/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info --private-key=/etc/pki/vdsm/ovn/ovn-key.pem --certificate=/etc/pki/vdsm/ovn/ovn-cert.pem --ca-cert=/etc/pki/vdsm/ovn/ca-cert.pem --user openvswitch:openvswitch --no-chdir --log-file=/var/log/ovn/ovn-controller.log --pidfile=/run/ovn/ovn-controller.pid --detach
system_u:system_r:unconfined_service_t:s0 vdsm 31636   1  0 08:56 ?        00:00:17 /usr/libexec/platform-python /usr/sbin/momd -c /etc/vdsm/mom.conf
system_u:system_r:unconfined_service_t:s0 vdsm 35622   1  0 08:57 ?        00:00:45 /usr/libexec/platform-python /usr/libexec/ovirt-hosted-engine-ha/ovirt-ha-broker
system_u:system_r:unconfined_service_t:s0 vdsm 35956   1  0 08:57 ?        00:00:17 /usr/libexec/platform-python /usr/libexec/ovirt-hosted-engine-ha/ovirt-ha-agent

I don't see any AVCs other than:
# grep "avc:  denied" /var/log/audit/audit.log
type=AVC msg=audit(1659516992.873:3152): avc:  denied  { add_name } for  pid=30353 comm="ovs-monitor-ips" name="ipsec.conf" scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1659516992.873:3153): avc:  denied  { add_name } for  pid=30353 comm="ovs-monitor-ips" name="ipsec.secrets" scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0

So is it perhaps just an upgrade issue? selinux labeling is handled in a special way in RHVH upgrades due to lvm layers (see https://github.com/oVirt/imgbased/blob/master/src/imgbased/plugins/osupdater.py)
Comment 11 Zdenek Pytela 2022-08-03 13:56:23 UTC 
(In reply to Michal Skrivanek from comment #10)
> (In reply to Zdenek Pytela from comment #6)
> > As momd seems to be the service, can you try
> > 
> >   # chcon -t virtd_exec_t /usr/sbin/momd
> > 
> > and reproduce again? This change will persist reboot, but not reinstallation.
> 
> why momd?
> I don't see a reason why momd or ovirt-imageio or ovirt-ha-* would ever talk
> to lldpad.

I am sorry I don't understand the background so it was just a blind shot, but momd was one of two services reported running in the unconfined_service_t context. Our goal is to find the service lldpad tries to communicate with.
Comment 12 Martin Perina 2022-08-04 07:52:35 UTC 
As mentioned above the way how selinux labeling is appliend on RHVH is different to then way how it happens on RHEL, because RHVH is an appliance based system. So to verify functonality of security context fixes included in BZ2095184 for RHVH we need to do following:

1. New installation of RHVH 4.5.1/4.5.2 based on RHEL 8.6.0.z with selinux-policy-3.14.3-95.el8_6.1
    - After addding the hypervisor to RHVM below service should have virtd_exec_t security context:
        /usr/libexec/vdsm/daemonAdapter
        /usr/libexec/vdsm/respawn
        /usr/libexec/vdsm/supervdsmd
        /usr/libexec/vdsm/vdsmd
    - Integration with lldpad works fine

2. Upgrade of RHVH 4.4.10 based on RHEL 8.5 to RHVH 4.5.1/4.5.2 based on RHEL 8.6.0.z with selinux-policy-3.14.3-95.el8_6.1
    - After addding the hypervisor to RHVM below service should have virtd_exec_t security context:
        /usr/libexec/vdsm/daemonAdapter
        /usr/libexec/vdsm/respawn
        /usr/libexec/vdsm/supervdsmd
        /usr/libexec/vdsm/vdsmd
    - Integration with lldpad works fine

Michael/Chen could you please work together to verify those flows?
Comment 13 Michael Burman 2022-08-04 08:06:09 UTC 
(In reply to Martin Perina from comment #12)
> As mentioned above the way how selinux labeling is appliend on RHVH is
> different to then way how it happens on RHEL, because RHVH is an appliance
> based system. So to verify functonality of security context fixes included
> in BZ2095184 for RHVH we need to do following:
> 
> 1. New installation of RHVH 4.5.1/4.5.2 based on RHEL 8.6.0.z with
> selinux-policy-3.14.3-95.el8_6.1
>     - After addding the hypervisor to RHVM below service should have
> virtd_exec_t security context:
>         /usr/libexec/vdsm/daemonAdapter
>         /usr/libexec/vdsm/respawn
>         /usr/libexec/vdsm/supervdsmd
>         /usr/libexec/vdsm/vdsmd
>     - Integration with lldpad works fine
> 
> 2. Upgrade of RHVH 4.4.10 based on RHEL 8.5 to RHVH 4.5.1/4.5.2 based on
> RHEL 8.6.0.z with selinux-policy-3.14.3-95.el8_6.1
>     - After addding the hypervisor to RHVM below service should have
> virtd_exec_t security context:
>         /usr/libexec/vdsm/daemonAdapter
>         /usr/libexec/vdsm/respawn
>         /usr/libexec/vdsm/supervdsmd
>         /usr/libexec/vdsm/vdsmd
>     - Integration with lldpad works fine
> 
> Michael/Chen could you please work together to verify those flows?

Chen is on it, I will check the lldpad functionality.
Comment 15 Martin Perina 2022-08-10 12:27:25 UTC 
lldpad AVC denials are not longer appearing and lldpad works fine after upgrade of selinux policy. There are still some AVC denials, but they are caused by RHVH upgrade process, which need to apply selinux updates on the content of the new image while still running the old image (more info at BZ2020997). The important part is that RHVH is fully funtional after reboot at the end of upgrade, we can close this bug
Comment 16 Zdenek Pytela 2022-08-11 14:55:46 UTC 
Closing this bz given the answer in comment#15.
Note You need to log in before you can comment on or make changes to this bug.