Bug 809910

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;

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 } ;

The file is created by libvirt, so flipping the component.

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;
    else
        oflags |= O_TRUNC;

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

So Dan we want to allow a confiend domain to write to a virt_home_t file.

So these are not treated as log files, and two svirt_t could use it to communicate or use it to attack another svirt.

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

Dan what process is creating

 $HOME/.libvirt/qemu/log

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

(gentle ping)

Marc-Andre can you try selinux-policy-3.10.0-116.fc17 Which should have the fix I suggested.

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

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
selinux-policy-3.10.0-116.fc17.noarch

selinux-policy-3.10.0-117.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-117.fc17

*** Bug 815078 has been marked as a duplicate of this bug. ***

It looks like the problem is this is not created by svirt_t.

If it was created by libvirt then libvirt needs to label it.

selinux-policy-3.10.0-118.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-118.fc17

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:
https://admin.fedoraproject.org/updates/FEDORA-2012-6452/selinux-policy-3.10.0-118.fc17
then log in and leave karma (feedback).

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.

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.

tried:
restorecon -R ~/.libvirt

next:
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

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

I encountered this same issue on a Fedora 17 x86-64 machine freshly-installed on May 18.

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.

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

semodule -r mypol


Fixed in selinux-policy-3.10.0-126.fc17.noarch

*** Bug 825546 has been marked as a duplicate of this bug. ***

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

Works for me.


Installed packages from Koji:
selinux-policy-3.10.0-127.fc17.noarch.rpm
selinux-policy-targeted-3.10.0-127.fc17.noarch.rpm

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

Works for me.

So you still need to run restorecon.

*** Bug 802551 has been marked as a duplicate of this bug. ***

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?

Yes

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?

Just closing as CURRENTRELEASE, someone reopen if I'm wrong.

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.

Reopening.

(btw: I don't know if it matters, but I have also been using virt-manager.)

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?

Okay I can reproduce on fully up to date F17, my guess is it's also an issue on F18.

Reproducer:

$ 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?

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

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.

Well it should work on F18 without problems.

Wasn't this fixed like many months ago?

I think so.