Description of problem: When running migration operation as part of RHTS, it fails with following selinux denial: type=SYSCALL msg=audit(1241560853.309:194): arch=c000003e syscall=59 success=no exit=-13 a0=7fff4667b115 a1=1112b450 a2=7fff4667b8b0 a3=7fff4667d8da items=0 ppid=2009 pid=2013 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="virsh" exe="/usr/bin/virsh" subj=system_u:system_r:xm_t:s0 key=(null) type=AVC msg=audit(1241560853.309:194): avc: denied { execute } for pid=2013 comm="virsh" name="ssh" dev=dm-0 ino=2538923 scontext=system_u:system_r:xm_t:s0 tcontext=system_u:object_r:ssh_exec_t:s0 tclass=file This doesn't happen when migration is done manually but does happen everytime when the migration testing is running on rhts as part of the init process. It'd be nice to have this fix soon, as this will prevent us from running libvirt migration tests over ssh. Version-Release number of selected component (if applicable): # rpm -qa | egrep "selinux|libvirt" | grep -v rh-tests libselinux-devel-1.33.4-5.1.el5 libselinux-1.33.4-5.1.el5 libselinux-python-1.33.4-5.1.el5 libselinux-utils-1.33.4-5.1.el5 libvirt-0.3.3-14.el5 selinux-policy-targeted-2.4.6-203.el5 libvirt-0.3.3-14.el5 libselinux-1.33.4-5.1.el5 selinux-policy-2.4.6-203.el5 libvirt-python-0.3.3-14.el5 libselinux-devel-1.33.4-5.1.el5 How reproducible: Everytime on rhts.
Can you run the test in permissive mode, to collect all of the AVC messages?
Created attachment 343694 [details] audit.log of the rhts job when it's run on permissive mode..
The log file for this test should not be in /.virtinst/virt.log If this is just for test output, it should be labeled correctly. I am adding ssh_basic_client_template(xm,xm_t,system_r) Fixed in selinux-policy-2.4.6-235.el5
virt-install program creates ~/.virtinst/virt.log file . Since it's running as init, the home dir is / . Thanks, will try selinux-policy-2.4.6-235.el5 .
In order to do testing with SELinux, you need to setup test labeling correctly. Maybe the HOMEDIR needs to be set as a temporary directory which the test logs.
Try selinux-policy-2.4.6-236.el5
This home directory is all mislabeled. Restorecon -R -v /root How did the files get there? What process put them there, since it did not correct the labeling the test is failing.
They are created earlier in the test when passwordless ssh is set up between the hosts..
Well the test should run restorecon on them after creating them restorecon -R -v /root
Also /home if they are created there.
Fixed in selinux-policy-2.4.6-241.el5
Got the following error with selinux-policy-2.4.6-252.el5 : type=SYSCALL msg=audit(1248209517.092:59): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=7fffd62a7c20 a2=6e a3=0 items=0 ppid=31567 pid=31583 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ssh" exe="/usr/bin/ssh" subj=system_u:system_r:xm_ssh_t:s0 key=(null) type=AVC msg=audit(1248209517.092:59): avc: denied { search } for pid=31583 comm="ssh" name="ssh-uhivM30485" dev=dm-0 ino=6750328 scontext=system_u:system_r:xm_ssh_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir
This looks like the xm_ssh command is being started within the initrc_tmp_t directory, which is causing the application to getattr on the current working directory. So I thikn you test is in correct, could you cd / before execuing ssh in the test?
This is not a problem of the user context, the problem is the location of where the ssh is being executed I believe. If you run the test in permissive mode, you might generate additional AVC message. Is there a directory in /tmp that is being created by your test?
(In reply to comment #30) > This is not a problem of the user context, the problem is the location of > where the ssh is being executed I believe. If you run the test in permissive > mode, you might generate additional AVC message. > > > Is there a directory in /tmp that is being created by your test? No there is not. However rhts itself creates log files/dirs inside the /tmp directory. I will run this in permissive mode to see what else i can get.
Gurhan, any update in permissive mode?
Created attachment 355434 [details] Permissive mode audit.log, july 28th 2009
Running the test with: runcon -t unconfined_t -- virsh migrate ${guest} xen+ssh://root@$remotehost instead of virsh migrate ${guest} xen+ssh://root@$remotehost works.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1242.html