Bug 771105

This was triggered by the following command:

sudo virt-install -l http://download.fedoraproject.org/pub/fedora/linux/releases/16/Fedora/x86_64/os --ram 1024 --disk /home/greenrd/f16.img,size=10 --name F16

which failed.

I think we could consider to run qemu-dm in the xend_t domain.

Robin,
could you try to execute

chcon -t bin_t /usr/lib/xen/bin/qemu-dm 

and re-test it. Thank you.

(In reply to comment #2)
> chcon -t bin_t /usr/lib/xen/bin/qemu-dm 
> 
> and re-test it. Thank you.

That worked - thanks!

Although, I am still puzzled about what happened previously, because even after running audit2allow and semodule -i on the first denied message, and running my command again which produced a different denied message, and running audit2allow and semodule -i on both messages, my command still failed in the same way, without any denied messages in audit.log! So I had to setenforce 0 - that was the only way to make it work, before you gave me this solution.

Note: to undo my workarounds, I ran

semodule -r virt-install
setenforce 1

before running this test.

Ah, I apologise, there were plenty of avc denied messages previously - I just didn't see them, because for some reason sealert didn't tell me about them.

There were no avc denied messages when I ran it just now.

That seems like a good idea.

Unfortunately I am now getting a number of avc denied messages when I try to use xend and virt-manager, which I didn't get before. I'm not sure whether this change is the cause of that though.

Could you attach the AVC's

Created attachment 551037 [details]
avcs

Ok, the problem is most of xend files/dirs are created with virt_*_t label because there is no transition.

Could you execute these steps

# semodule -d unconfined
# setenforce 0

re-test it please

# ausearch -m avc -ts recent > /tmp/avc-excerpt1.txt
# semodule -e unconfined
# setenforce 1

Created attachment 551338 [details]
avcs after semodule -d unconfined

I should clarify that comment 6 above refers to me performing *other* actions involving xen, *not* the virt-install command. Just wanted to make sure that was clear.

I added fixed to selinux-policy-3.10.0-72.fc16

selinux-policy-3.10.0-72.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-72.fc16

Package selinux-policy-3.10.0-72.fc16:
* should fix your issue,
* was pushed to the Fedora 16 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-72.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-0639/selinux-policy-3.10.0-72.fc16
then log in and leave karma (feedback).

selinux-policy-3.10.0-72.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Hi - I have selinux-policy 3.10.0-80.fc16 and am still getting the original problem (AVC below).

If I run the suggestion from comment #2

chcon -t bin_t /usr/lib/xen/bin/qemu-dm 

I get past the problem.  I still get more denials.

Is there something other than having the latest selinux-policy installed that is required?

Is the latest selinux-policy supposed to have fixed the original and subsequent (comment #9, perhaps?) problems?

# rpm -qi selinux-policy
Name        : selinux-policy
Version     : 3.10.0
Release     : 80.fc16
Architecture: noarch
Install Date: Mon 26 Mar 2012 09:07:47 AM HKT
Group       : System Environment/Base
Size        : 9284469
License     : GPLv2+
Signature   : RSA/SHA256, Wed 21 Mar 2012 12:28:33 AM HKT, Key ID 067f00b6a82ba4b7
Source RPM  : selinux-policy-3.10.0-80.fc16.src.rpm
Build Date  : Tue 13 Mar 2012 07:29:08 PM HKT
Build Host  : x86-07.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : http://oss.tresys.com/repos/refpolicy/
Summary     : SELinux policy configuration
Description :
SELinux Reference Policy - modular.
Based off of reference policy: Checked out revision  2.20091117


# sealert -l 4b65b35f-6bb1-49f9-91e4-ac11d512e7c1
No protocol specified
No protocol specified
No protocol specified
No protocol specified
SELinux is preventing /usr/lib/xen/bin/qemu-dm from 'read, write' accesses on the chr_file ptmx.

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

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


Additional Information:
Source Context                system_u:system_r:qemu_dm_t:s0
Target Context                system_u:object_r:ptmx_t:s0
Target Objects                ptmx [ chr_file ]
Source                        qemu-dm
Source Path                   /usr/lib/xen/bin/qemu-dm
Port                          <Unknown>
Host                          zz
Source RPM Packages           xen-runtime-4.1.2-6.fc16.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-80.fc16.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     zz
Platform                      Linux zz 3.3.0-8.fc16.x86_64 #1 SMP Thu Mar 29
                              18:37:19 UTC 2012 x86_64 x86_64
Alert Count                   7
First Seen                    Mon 02 Apr 2012 01:16:59 PM HKT
Last Seen                     Mon 02 Apr 2012 02:00:21 PM HKT
Local ID                      4b65b35f-6bb1-49f9-91e4-ac11d512e7c1

Raw Audit Messages
type=AVC msg=audit(1333346421.265:13013): avc:  denied  { read write } for  pid=32161 comm="qemu-dm" name="ptmx" dev="devtmpfs" ino=1132 scontext=system_u:system_r:qemu_dm_t:
s0 tcontext=system_u:object_r:ptmx_t:s0 tclass=chr_file


type=SYSCALL msg=audit(1333346421.265:13013): arch=x86_64 syscall=open success=no exit=EACCES a0=7fa4a6d5040d a1=2 a2=0 a3=7fff8cc8e130 items=0 ppid=1432 pid=32161 auid=42949
67295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=qemu-dm exe=/usr/lib/xen/bin/qemu-dm subj=system_u:system_r:qemu_dm_t:s0 key=(nul
l)

Hash: qemu-dm,qemu_dm_t,ptmx_t,chr_file,read,write

audit2allow

#============= qemu_dm_t ==============
allow qemu_dm_t ptmx_t:chr_file { read write };

audit2allow -R

#============= qemu_dm_t ==============
allow qemu_dm_t ptmx_t:chr_file { read write };

I apologize, my fault. 

This has been fixed only in F17. Backporting fixes to F16.

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.