On Fedora 44/45, SELinux repeatedly logs AVCs where the domain tuned_t attempts to acquire the mac_admin capability (class capability2). These AVCs are labeled under comm="chcon", but:

- no chcon binary is executed,
- no tuned script or plugin contains chcon,
- tuned_t should never request mac_admin,
- the operation appears to be an internal kernel capability request mislabeled by SELinux.

This strongly suggests a policy bug: incorrect capability assignment, incorrect domain transition, or incorrect command labeling.


Reproducible: Always

Steps to Reproduce:
1. Install Fedora 44/45 with SELinux enforcing.
2. Enable tuned:
   systemctl enable --now tuned
3. Observe AVCs:
   ausearch -c chcon
4. Verify chcon is not executed:
   ausearch -c chcon -x chcon
5. Verify tuned does not call chcon:
   grep -R "chcon" /usr/lib/tuned /etc/tuned

Actual Results:
SELinux logs repeated AVCs:

avc:  denied  { mac_admin } for  pid=13031 comm="chcon" capability=33
scontext=system_u:system_r:tuned_t:s0
tcontext=system_u:system_r:tuned_t:s0
tclass=capability2 permissive=0

- tuned_t requests mac_admin
- SELinux labels the operation as "chcon"
- no chcon binary is executed
- AVCs occur at every tuned startup


Expected Results:
- tuned_t should not request mac_admin
- tuned_t should not be associated with "chcon"
- SELinux should not mislabel internal operations as chcon
- no AVCs should be generated during normal tuned operation


Additional Information:
ausearch -c chcon -x chcon → <no matches>
grep -R "chcon" /usr/lib/tuned /etc/tuned → no output

This confirms:
- chcon is not executed
- tuned does not call chcon
- SELinux is mislabeling an internal capability request