Bug 2111410

Is this RHVH authentic bug?

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.

(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)

(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.

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?

(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.

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

Closing this bz given the answer in comment#15.