Bug 2221576 - SELinux is preventing qemu-ga from 'getattr' accesses on the blk_file /dev/vda5.
Summary: SELinux is preventing qemu-ga from 'getattr' accesses on the blk_file /dev/vda5.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 38
Hardware: x86_64
OS: Unspecified
medium
unspecified
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:f8de7e59abd4546cadec4aae93b...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-07-10 07:40 UTC by dittmann+redhat
Modified: 2023-08-01 02:49 UTC (History)
9 users (show)

Fixed In Version: selinux-policy-38.22-1.fc38
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-01 02:49:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: description (1.89 KB, text/plain)
2023-07-10 07:40 UTC, dittmann+redhat
no flags Details
File: os_info (684 bytes, text/plain)
2023-07-10 07:40 UTC, dittmann+redhat
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github fedora-selinux selinux-policy pull 1783 0 None open Allow qemu-ga get fixed disk devices attributes 2023-07-17 10:43:51 UTC

Description dittmann+redhat 2023-07-10 07:40:51 UTC
Description of problem:
- running Fedora 38 Cloud in OpenShift and Kubernetes cluster v1.26.5
```
sudo dnf groupinstall -y "Cinnamon Desktop"
sudo systemctl set-default graphical.target
reboot
# login
```
- SELinux pops up from time to time, saying, qemu-ga wants to execute `getattr` on /dev/vda5 (fedora partition on virtual-aware disk)
SELinux is preventing qemu-ga from 'getattr' accesses on the blk_file /dev/vda5.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that qemu-ga should be allowed getattr access on the vda5 blk_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'qemu-ga' --raw | audit2allow -M my-qemuga
# semodule -X 300 -i my-qemuga.pp

Additional Information:
Source Context                system_u:system_r:virt_qemu_ga_t:s0
Target Context                system_u:object_r:fixed_disk_device_t:s0
Target Objects                /dev/vda5 [ blk_file ]
Source                        qemu-ga
Source Path                   qemu-ga
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-38.20-1.fc38.noarch
Local Policy RPM              selinux-policy-targeted-38.20-1.fc38.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 6.3.11-200.fc38.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Sun Jul 2 13:17:31 UTC 2023 x86_64
Alert Count                   404
First Seen                    2023-07-09 17:16:40 UTC
Last Seen                     2023-07-10 06:59:47 UTC
Local ID                      b479245d-509e-4192-b1fd-a6a965a0c845

Raw Audit Messages
type=AVC msg=audit(1688972387.597:836): avc:  denied  { getattr } for  pid=1154 comm="qemu-ga" path="/dev/vda5" dev="devtmpfs" ino=426 scontext=system_u:system_r:virt_qemu_ga_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=0


Hash: qemu-ga,virt_qemu_ga_t,fixed_disk_device_t,blk_file,getattr

Version-Release number of selected component:
selinux-policy-targeted-38.20-1.fc38.noarch

Additional info:
reporter:       libreport-2.17.11
reason:         SELinux is preventing qemu-ga from 'getattr' accesses on the blk_file /dev/vda5.
package:        selinux-policy-targeted-38.20-1.fc38.noarch
component:      selinux-policy
hashmarkername: setroubleshoot
type:           libreport
kernel:         6.3.11-200.fc38.x86_64
event_log:      2023-07-10-07:04:09> Looking for similar problems in bugzilla
component:      selinux-policy

Comment 1 dittmann+redhat 2023-07-10 07:40:54 UTC
Created attachment 1974942 [details]
File: description

Comment 2 dittmann+redhat 2023-07-10 07:40:55 UTC
Created attachment 1974943 [details]
File: os_info

Comment 3 Zdenek Pytela 2023-07-13 16:47:22 UTC
Helo,

Can you check if allowing the reported permission denial is sufficient?

  # cat local_qemu_disk.cil
(allow virt_qemu_ga_t fixed_disk_device_t (blk_file (getattr)))
  # semodule -i local_qemu_disk.cil
<reproduce>
  # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Comment 4 dittmann+redhat 2023-07-17 09:56:45 UTC
I used `sudo semodule -X 300 -r my-qemuga` to undo my actions. The SELinux pop-ups re-appear. Where do I find `local_qemu_disk.cil`?

Comment 5 Zdenek Pytela 2023-07-17 10:08:53 UTC
(In reply to dittmann+redhat from comment #4)
> I used `sudo semodule -X 300 -r my-qemuga` to undo my actions. The SELinux
> pop-ups re-appear. Where do I find `local_qemu_disk.cil`?

Create the file with the content as suggested.

Comment 6 dittmann+redhat 2023-07-17 10:26:58 UTC
With these lines the pop-ups disappear and no new entries are found in ausearch:
```
echo "(allow virt_qemu_ga_t fixed_disk_device_t (blk_file (getattr)))" > local_qemu_disk.cil
sudo semodule -I local_qemu_disk.cil
sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
```

Should/Can this be done by OpenShift, SELinux, or `qemu-guest-agent` automagically?

```
$ qemu-ga --version
QEMU Guest Agent 7.2.1
```

Comment 7 dittmann+redhat 2023-07-17 10:36:48 UTC
`semodule -i` of course:

```
echo "(allow virt_qemu_ga_t fixed_disk_device_t (blk_file (getattr)))" > local_qemu_disk.cil
sudo semodule -i local_qemu_disk.cil
sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
```

Comment 8 Zdenek Pytela 2023-07-17 10:43:51 UTC
(In reply to dittmann+redhat from comment #6)
> Should/Can this be done by OpenShift, SELinux, or `qemu-guest-agent`
> automagically?
This should go to selinux-policy.

Comment 9 Fedora Update System 2023-07-25 17:23:22 UTC
FEDORA-2023-0b46b767d3 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-0b46b767d3

Comment 10 Fedora Update System 2023-07-26 02:09:42 UTC
FEDORA-2023-0b46b767d3 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-0b46b767d3`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-0b46b767d3

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 11 Fedora Update System 2023-08-01 02:49:10 UTC
FEDORA-2023-0b46b767d3 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


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