Bug 809910 - libvirt doesn't create ~/.libvirt with any selinux labels, breaks qemu:///session guest startup
libvirt doesn't create ~/.libvirt with any selinux labels, breaks qemu:///ses...
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jiri Denemark
Fedora Extras Quality Assurance
: Reopened
: 802551 815078 825546 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2012-04-04 12:21 EDT by Luke Macken
Modified: 2016-09-19 22:43 EDT (History)
38 users (show)

See Also:
Fixed In Version: selinux-policy-3.10.0-118.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-06-25 09:28:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Luke Macken 2012-04-04 12:21:57 EDT
After a fresh F17 (pre-beta) install, I fired up the new gnome-boxes app, and pointed it at an ISO. I immediately got these SELinux AVCs:

    type=AVC msg=audit(1333553539.711:667): avc:  denied  { write } for
    pid=24412 comm="qemu-kvm" name="lib" dev="dm-2" ino=1055522
    tcontext=unconfined_u:object_r:virt_home_t:s0 tclass=dir

    type=AVC msg=audit(1333553539.688:666): avc:  denied  { write } for
    pid=24412 comm="qemu-kvm"
    dev="dm-2" ino=1188986 scontext=system_u:system_r:svirt_t:s0:c682,c986
    tcontext=unconfined_u:object_r:virt_home_t:s0 tclass=file

After discussion in #fedora-selinux, it was mentioned that this is most
likely a bug in qemu-kvm, because the current SELinux policy allows for svirt_t to append virt_home_t files. So, it seems that this log should be opened for appending, not for writing.

Comment 1 Daniel Berrange 2012-04-04 12:27:39 EDT
Those audit messages are both for 'write' which is applicable regardless of whether QEMU creates vs appends data. 

audit2allow says the policy needs this:

#============= svirt_t ==============
#!!!! The source type 'svirt_t' can write to a 'dir' of the following types:
# var_t, tmp_t, tmpfs_t, svirt_tmp_t, hugetlbfs_t, virt_cache_t, svirt_image_t, svirt_tmpfs_t, var_run_t, qemu_var_run_t, dosfs_t

allow svirt_t virt_home_t:dir write;
allow svirt_t virt_home_t:file write;
Comment 2 Miroslav Grepl 2012-04-04 12:53:25 EDT
I thought we fixed this one. We have in the policy

# sesearch -A -s svirt_t -t virt_home_t -c file 
WARNING: Policy would be downgraded from version 27 to 26.
Found 1 semantic av rules:
   allow svirt_t virt_home_t : file { ioctl getattr lock append open } ;
Comment 3 Paolo Bonzini 2012-04-05 08:53:01 EDT
The file is created by libvirt, so flipping the component.
Comment 4 Paolo Bonzini 2012-04-05 08:55:18 EDT
Though actually libvirt code says why it is writing and not appending, perhaps modifying the SELinux policy to allow write is really the sensible thing to do.

    /* Only logrotate files in /var/log, so only append if running privileged */
    if (driver->privileged || append)
        oflags |= O_APPEND;
        oflags |= O_TRUNC;
Comment 5 Daniel Berrange 2012-04-05 09:18:27 EDT
Again, the create vs append distinction is irrelevant here.

The AVC message is about 'denied { write }', not about 'denied { create }' / 'denied { append }'. Either this is missing from the policy in which case it needs adding, or this is already in the policy, in which case NOTABUG
Comment 6 Daniel Walsh 2012-04-09 16:18:41 EDT
So Dan we want to allow a confiend domain to write to a virt_home_t file.
Comment 7 Daniel Walsh 2012-04-09 16:21:16 EDT
So these are not treated as log files, and two svirt_t could use it to communicate or use it to attack another svirt.
Comment 8 Daniel Berrange 2012-04-10 04:17:44 EDT
Hmm, it seems that everything under $HOME/.libvirt is being given the same label, which is wrong - we need some finer grained labelling here.

The equivalence between existing privileged dirs & non-privileged dirs is thus:

  $HOME/.libvirt/qemu/log     <-> /var/log/libvirt/qemu
  $HOME/.libvirt/qemu/run     <-> /var/run/libvirt/qemu
  $HOME/.libvirt/qemu/lib     <-> /var/lib/libvirt/qemu
Comment 9 Daniel Walsh 2012-04-10 15:15:21 EDT
Dan what process is creating


If this is created via libvirt, then we can allow svirt_t to transition to a new type in this directory svirt_home_t.

Something like
manage_dirs_pattern(svirt_t, svirt_home_t, svirt_home_t)
manage_files_pattern(svirt_t, svirt_home_t, svirt_home_t)
manage_sock_files_pattern(svirt_t, svirt_home_t, svirt_home_t)
filetrans_pattern(svirt_t, virt_home_t, svirt_home_t, { dir sock_file file })
Comment 10 Marc-Andre Lureau 2012-04-19 20:57:13 EDT
(gentle ping)
Comment 11 Daniel Walsh 2012-04-20 09:37:01 EDT
Marc-Andre can you try selinux-policy-3.10.0-116.fc17 Which should have the fix I suggested.
Comment 12 Marc-Andre Lureau 2012-04-20 10:04:44 EDT
(In reply to comment #11)
> Marc-Andre can you try selinux-policy-3.10.0-116.fc17 Which should have the fix
> I suggested.

That's what I used. Then I added the suggested generated module, and it worked. (note: I am really not familiar with selinux, and usually disable it, sorry :/)
Comment 13 Daniel Walsh 2012-04-20 11:14:44 EDT
Ok the current policy I am looking at has

sesearch -A -s svirt_t -t virt_home_t -c dir -C
   allow svirt_t virt_home_t : dir { ioctl read write getattr lock add_name remove_name search open } ; 

Which should have allowed svirt_t to create an svirt_home_t file in the virt_home_t directory.

rpm -q selinux-policy
Comment 14 Fedora Update System 2012-04-23 02:44:04 EDT
selinux-policy-3.10.0-117.fc17 has been submitted as an update for Fedora 17.
Comment 15 Miroslav Grepl 2012-04-23 08:31:03 EDT
*** Bug 815078 has been marked as a duplicate of this bug. ***
Comment 16 Miroslav Grepl 2012-04-23 08:40:50 EDT
It looks like the problem is this is not created by svirt_t.
Comment 17 Daniel Walsh 2012-04-23 10:59:47 EDT
If it was created by libvirt then libvirt needs to label it.
Comment 18 Fedora Update System 2012-04-23 20:56:50 EDT
selinux-policy-3.10.0-118.fc17 has been submitted as an update for Fedora 17.
Comment 19 Fedora Update System 2012-04-23 23:14:55 EDT
Package selinux-policy-3.10.0-118.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-118.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 20 Fedora Update System 2012-04-25 00:59:01 EDT
selinux-policy-3.10.0-118.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Martin 2012-05-03 05:55:17 EDT
I have updated F17 with selinux-policy-3.10.0-118.fc17.noarch and qemu-kvm-1.0-17.fc17.x86_64 and bug still persist.

Using Gnome Boxes.

restorecon -R ~/.libvirt

rm -rf ~/.libvirt

ls -Z .libvirt/qemu/
drwxrwxr-x. mholec mholec unconfined_u:object_r:virt_home_t:s0 log
drwxrwxr-x. mholec mholec unconfined_u:object_r:virt_home_t:s0 run

ls -Z .libvirt/qemu/log/
-rw-------. mholec mholec unconfined_u:object_r:virt_home_t:s0 fedora-17-beta-kde-x86_64-201204071420.iso.log

ausearch -m AVC -ts recent
time->Thu May  3 11:46:02 2012
type=SYSCALL msg=audit(1336038362.681:122): arch=c000003e syscall=59 success=yes exit=0 a0=7fcec800b8c0 a1=7fcec8001bb0 a2=7fcec800b200 a3=0 items=0 ppid=1 pid=4017 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c196,c498 key=(null)
type=AVC msg=audit(1336038362.681:122): avc:  denied  { write } for  pid=4017 comm="qemu-kvm" path="/home/mholec/.libvirt/qemu/log/fedora-17-beta-kde-x86_64-201204071420.iso.log" dev="dm-7" ino=2834 scontext=system_u:system_r:svirt_t:s0:c196,c498 tcontext=unconfined_u:object_r:virt_home_t:s0 tclass=file
type=AVC msg=audit(1336038362.681:122): avc:  denied  { write } for  pid=4017 comm="qemu-kvm" path="/home/mholec/.libvirt/qemu/log/fedora-17-beta-kde-x86_64-201204071420.iso.log" dev="dm-7" ino=2834 scontext=system_u:system_r:svirt_t:s0:c196,c498 tcontext=unconfined_u:object_r:virt_home_t:s0 tclass=file
Comment 22 Daniel Walsh 2012-05-03 10:49:56 EDT
Martin chcon -t svirt_home_t  /home/mholec/.libvirt/qemu/log/fedora-17-beta-kde-x86_64-201204071420.iso.log

The problem is we are not maintaining the label on a restorecon.

If the only content that will go into the log directory is going to be svirt_home_t content, we should change the label, and also add svirt_home_t as a customizable_type
Comment 23 Jason Brooks 2012-05-19 13:20:10 EDT
I encountered this same issue on a Fedora 17 x86-64 machine freshly-installed on May 18.
Comment 24 Christophe Fergeau 2012-05-21 03:29:56 EDT
Bug #822958 has:

Daniel Walsh 2012-05-18 13:54:09 EDT

Could you 

rm /home/test/.libvirt/qemu/log/*.log
chcon -t svirt_home_t -R /home/test/.libvirt/qemu

And then try it out?

This is the new labeling I will add to F17.
Comment 25 Jason Brooks 2012-05-23 11:29:35 EDT
(In reply to comment #24)
> Bug #822958 has:
> Daniel Walsh 2012-05-18 13:54:09 EDT
> Could you 
> rm /home/test/.libvirt/qemu/log/*.log
> chcon -t svirt_home_t -R /home/test/.libvirt/qemu

I did this and it worked. I had, however, already allowed the access as suggested by the troubleshooter. Before trying the fix referenced here, though, I ran "semodule -e mypol.pp" assuming that that undid the policy change suggested by the troubleshooter.

> And then try it out?
> This is the new labeling I will add to F17.
Comment 26 Daniel Walsh 2012-05-24 11:11:36 EDT
semodule -r mypol

Fixed in selinux-policy-3.10.0-126.fc17.noarch
Comment 27 Miroslav Grepl 2012-05-28 04:57:05 EDT
*** Bug 825546 has been marked as a duplicate of this bug. ***
Comment 28 Martin 2012-05-28 09:57:13 EDT
rm .libvirt/qemu/log/*.log
chcon -t svirt_home_t -R .libvirt/qemu

Works for me.

Installed packages from Koji:

rm -rf .libvirt/
gnome-boxes #Box creation failed
restorecon -v -R .libvirt/ #fixes issue

Works for me.
Comment 29 Miroslav Grepl 2012-05-29 01:38:10 EDT
So you still need to run restorecon.
Comment 30 Miroslav Grepl 2012-06-04 05:04:13 EDT
*** Bug 802551 has been marked as a duplicate of this bug. ***
Comment 31 Zeeshan Ali 2012-06-04 09:52:33 EDT
Do I understand correctly that people who had Boxes and libvirt installed *before* this issue was fixed, need to apply the commands that Martin did to solve problem on his machine?
Comment 32 Daniel Walsh 2012-06-04 10:40:08 EDT
Comment 33 Cole Robinson 2012-06-06 13:57:04 EDT
The bug status here is VERIFIED but I'm a bit confused... is there anything left to push to packages or can we close this?
Comment 34 Cole Robinson 2012-06-07 17:25:26 EDT
Just closing as CURRENTRELEASE, someone reopen if I'm wrong.
Comment 35 Mads Kiilerich 2012-08-10 08:43:12 EDT
I installed a f17 with netinst and thus got all updates as of today. When I ran gnome-boxes I saw this issue. The files in .libvirt is created as virt_home_t. restorecon would change them to svirt_home_t.

I would expect that the files should be created with the right domain from the beginning.


(btw: I don't know if it matters, but I have also been using virt-manager.)
Comment 36 M. Edward (Ed) Borasky 2012-09-06 19:33:32 EDT
I came here from bug 802551, which has been closed as a duplicate of this one. But bug 802551 accurately describes my symptoms. Is there something I need to do besides update all my packages so that GNOME Boxes stops failing to create a box?
Comment 37 Cole Robinson 2012-10-20 17:40:46 EDT
Okay I can reproduce on fully up to date F17, my guess is it's also an issue on F18.


$ mv ~/.libvirt libvirtbak
$ virsh --connect qemu:///session
$ define sessionpxe
$ start sessionpxe
error: Failed to start domain sessionpxe
error: internal error process exited while connecting to monitor: bind(unix:/home/crobinso/.libvirt/qemu/lib/sessionpxe.monitor): No such file or directory
chardev: opening backend "socket" failed

$ sudo ausearch --message avc | tail
type=SYSCALL msg=audit(1350768974.698:2379): arch=c000003e syscall=59 success=yes exit=0 a0=7ff0fc0c5f30 a1=7ff0fc0c2f80 a2=7ff0fc0c9a60 a3=7ff11f80c880 items=0 ppid=1 pid=21765 auid=1001 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=(none) ses=51 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c511,c521 key=(null)
type=AVC msg=audit(1350768974.698:2379): avc:  denied  { write } for  pid=21765 comm="qemu-kvm" path="/home/crobinso/.libvirt/qemu/log/sessionpxe.log" dev="sda2" ino=2891071 scontext=system_u:system_r:svirt_t:s0:c511,c521 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

As dwalsh says, libvirt needs to do the equivalent of restorecon on all the directories it makes. I think easiest way is to add a method in src/util somewhere that does the restorecon bit, call it on every file we create with virFileMakePath, but ignore any errors since not all files we create will have a default context.

dallan, can you get someone to take a look at this?
Comment 38 Cole Robinson 2012-10-20 17:41:58 EDT
And to clarify upstream is affected as well AFAICT, but ~/.libvirt isn't used anymore and instead it's a smattering of directories spread across /run, ~/.config, and ~/.cache IIRC
Comment 39 Cole Robinson 2012-12-08 19:39:27 EST
This is kinda working on F18 because restorecond watches ~/.config/* and ~/.cache/* to auto fix selinux labels. Though it doesn't cover /run, and users don't have to have restorecond running, so it would still be useful for libvirt to manually restorecon labels.
Comment 40 Miroslav Grepl 2012-12-10 04:52:23 EST
Well it should work on F18 without problems.
Comment 41 Zeeshan Ali 2013-06-24 19:25:05 EDT
Wasn't this fixed like many months ago?
Comment 42 Cole Robinson 2013-06-25 09:28:52 EDT
I think so.

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