Bug 1275603

Summary: SELinux is preventing qemu-system-x86 from 'write' accesses on the directory lib.
Product: [Fedora] Fedora Reporter: Mathieu Bridon <bochecha>
Component: selinux-policyAssignee: Lukas Vrabec <lvrabec>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: awilliam, dominick.grift, dwalsh, kparal, lvrabec, mgrepl, plautrba, robatino, sgallagh
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:696e0794213ed97b907fed3bdb6860e34719d5fd1c43eddff71c9dc39d2091f8;VARIANT_ID=workstation;
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-27 16:57:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1170821    

Description Mathieu Bridon 2015-10-27 10:13:02 UTC
Description of problem:
I tried creating a new VM with GNOME Boxes.
SELinux is preventing qemu-system-x86 from 'write' accesses on the directory lib.

*****  Plugin catchall_labels (83.8 confidence) suggests   *******************

If you want to allow qemu-system-x86 to have write access on the lib directory
Then you need to change the label on lib
Do
# semanage fcontext -a -t FILE_TYPE 'lib'
where FILE_TYPE is one of the following: dosfs_t, hugetlbfs_t, qemu_var_run_t, svirt_home_t, svirt_image_t, svirt_tmp_t, svirt_tmpfs_t, tmp_t, tmpfs_t, user_tmp_t, var_run_t, var_t, virt_cache_t, virt_home_t. 
Then execute: 
restorecon -v 'lib'


*****  Plugin catchall (17.1 confidence) suggests   **************************

If you believe that qemu-system-x86 should be allowed write access on the lib directory 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:
# grep qemu-system-x86 /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:svirt_t:s0:c244,c283
Target Context                unconfined_u:object_r:unlabeled_t:s0
Target Objects                lib [ dir ]
Source                        qemu-system-x86
Source Path                   qemu-system-x86
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           filesystem-3.2-35.fc23.x86_64
Policy RPM                    selinux-policy-3.13.1-152.fc23.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 4.2.3-300.fc23.x86_64 #1 SMP Mon
                              Oct 5 15:42:54 UTC 2015 x86_64 x86_64
Alert Count                   1
First Seen                    2015-10-27 11:11:31 CET
Last Seen                     2015-10-27 11:11:31 CET
Local ID                      011a10e3-5ac8-421b-be1e-7e79320d9ec8

Raw Audit Messages
type=AVC msg=audit(1445940691.118:630): avc:  denied  { write } for  pid=13569 comm="qemu-system-x86" name="lib" dev="sda2" ino=8913975 scontext=unconfined_u:unconfined_r:svirt_t:s0:c244,c283 tcontext=unconfined_u:object_r:unlabeled_t:s0 tclass=dir permissive=0


Hash: qemu-system-x86,svirt_t,unlabeled_t,dir,write

Version-Release number of selected component:
selinux-policy-3.13.1-152.fc23.noarch

Additional info:
reporter:       libreport-2.6.2
hashmarkername: setroubleshoot
kernel:         4.2.3-300.fc23.x86_64
type:           libreport

Comment 1 Fedora Blocker Bugs Application 2015-10-27 10:27:19 UTC
Proposed as a Blocker for 23-final by Fedora user bochecha using the blocker tracking app because:

 SELinux prevents GNOME Boxes from creating a virtual machine, which I would qualify as "basic functionality" for that application.

This violates the "Default application functionality" release criteria.

Comment 2 Kamil Páral 2015-10-27 14:32:23 UTC
I tried but couldn't reproduce this. I installed clean F23 RC3 Workstation Live, then used the same ISO image to install it inside Boxes. The VM boots fine both Live and installed, no SELinux alerts.

I have the same kernel and selinux-policy version as OP.

Comment 3 Kamil Páral 2015-10-27 14:34:04 UTC
Stephen Gallagher also tried to reproduce, also received no AVCs.

Comment 4 Lukas Vrabec 2015-10-27 14:37:11 UTC
*** Bug 1275607 has been marked as a duplicate of this bug. ***

Comment 5 Lukas Vrabec 2015-10-27 14:37:18 UTC
*** Bug 1275605 has been marked as a duplicate of this bug. ***

Comment 6 Stephen Gallagher 2015-10-27 14:40:09 UTC
I'm -1 blocker on this, since I can't reproduce it and I've tried.


Also, it's worth noting that all of the files referenced in these bugs are located within the user's home directory. It's possible that something got mislabeled if this home directory was reused or is hosted on NFS, etc. But it seems that it's not an issue for a freshly-installed system.

Comment 7 Lukas Vrabec 2015-10-27 14:41:29 UTC
Hi Mathieu, 

Did you try it on fresh installation? I believe you turn selinux off, then reboot system and then turn selinux on again. Please run:
"# restorecon -R -v /" 

This should fix your issue. 

Thank you guys for testing.

Comment 8 Mathieu Bridon 2015-10-27 15:00:32 UTC
(In reply to Stephen Gallagher from comment #6)
> Also, it's worth noting that all of the files referenced in these bugs are
> located within the user's home directory. It's possible that something got
> mislabeled if this home directory was reused or is hosted on NFS, etc. But
> it seems that it's not an issue for a freshly-installed system.

This is fresh new install, I did not reuse the home folder, it is not on NFS.

(In reply to Lukas Vrabec from comment #7)
> Hi Mathieu, 
> 
> Did you try it on fresh installation?

Yes.

> I believe you turn selinux off, then
> reboot system and then turn selinux on again.

I never turned SELinux off on this system since I installed it last Thursday.

I only did "setenforce 0" **after** I started running into this bug, because I needed the VM to do some work.

> Please run:
> "# restorecon -R -v /" 

Ok, I just did that.

Indeed, it restored the context of some files under ~/.local/share/gnome-boxes and ~/.config/libvirt

And now I don't seem to get any SELinux errors any more, so it was indeed a problem with mislabled files.

I'm really wondering why those files got mislabeled, though, but I guess that's not this bug.

Thanks.

Comment 9 Adam Williamson 2015-10-27 15:41:48 UTC
How did you do your install, Mathieu?

Comment 10 Mathieu Bridon 2015-10-27 15:50:31 UTC
I downloaded the latest (as of last Thursday morning, UTC+2) Workstation image from https://alt.fedoraproject.org/pub/alt/stage/?C=M;O=A

Then made a live USB, and installed the usual way.

Nothing special really.

Comment 11 Miroslav Grepl 2015-10-27 16:57:51 UTC
If we are not able to reproduce, I would close this bug. It could be some specific/install issue  which caused you got unlabeled_t for some dirs/files related to gnome-boxes and libvirt.

If we get a reproducer then we will investigate further.

Thanks.

Comment 12 Adam Williamson 2015-10-27 17:54:30 UTC
mathieu: can you post the exact image filename? That's safer than me trying to guess what you would have downloaded last Thursday.