Hi! What do I have to do to get qemu-kvm to run with selinux running with enforcing policy? I get these messages when I enable this policy: Mar 3 20:56:23 matrix kernel: [ 8972.482746] device vnet0 entered promiscuous mode Mar 3 20:56:23 matrix kernel: [ 8972.898943] br0: port 2(vnet0) entering learning state Mar 3 20:56:23 matrix kernel: [ 8972.901957] type=1400 audit(1236110183.820:20): avc: denied { execmem } for pid=6376 comm="kvm" scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=process Mar 3 20:56:23 matrix kernel: [ 8973.161318] type=1400 audit(1236110183.832:21): avc: denied { append } for pid=6379 comm="ifup" name="ifstate" dev=sda1 ino=1376380 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file Mar 3 20:56:23 matrix kernel: [ 8973.188371] br0: port 2(vnet0) entering disabled state Mar 3 20:56:23 matrix kernel: [ 8973.203666] device vnet0 left promiscuous mode Mar 3 20:56:23 matrix kernel: [ 8973.203675] br0: port 2(vnet0) entering disabled state Mar 3 20:56:23 matrix libvirtd: Received signal 17, dispatching to drivers Mar 3 20:56:23 matrix libvirtd: Received signal 17, dispatching to drivers Mar 3 20:56:23 matrix kernel: [ 8973.216362] type=1400 audit(1236110183.880:22): avc: denied { append } for pid=6387 comm="ifdown" name="ifstate" dev=sda1 ino=1376380 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file I've tried to set the type: chcon -t virt_image_t a01.img but all I got was: chcon: failed to change context of `a01.img' to `system_u:object_r:virt_image_t:s0': Invalid argument The host is a debian 5.0 machine. TIA Regards Michael
Michael Kress wrote:
Hi! What do I have to do to get qemu-kvm to run with selinux running with enforcing policy? I get these messages when I enable this policy: Mar 3 20:56:23 matrix kernel: [ 8972.482746] device vnet0 entered promiscuous mode Mar 3 20:56:23 matrix kernel: [ 8972.898943] br0: port 2(vnet0) entering learning state Mar 3 20:56:23 matrix kernel: [ 8972.901957] type=1400 audit(1236110183.820:20): avc: denied { execmem } for pid=6376 comm="kvm" scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=process Mar 3 20:56:23 matrix kernel: [ 8973.161318] type=1400 audit(1236110183.832:21): avc: denied { append } for pid=6379 comm="ifup" name="ifstate" dev=sda1 ino=1376380 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file Mar 3 20:56:23 matrix kernel: [ 8973.188371] br0: port 2(vnet0) entering disabled state Mar 3 20:56:23 matrix kernel: [ 8973.203666] device vnet0 left promiscuous mode Mar 3 20:56:23 matrix kernel: [ 8973.203675] br0: port 2(vnet0) entering disabled state Mar 3 20:56:23 matrix libvirtd: Received signal 17, dispatching to drivers Mar 3 20:56:23 matrix libvirtd: Received signal 17, dispatching to drivers Mar 3 20:56:23 matrix kernel: [ 8973.216362] type=1400 audit(1236110183.880:22): avc: denied { append } for pid=6387 comm="ifdown" name="ifstate" dev=sda1 ino=1376380 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
I've tried to set the type: chcon -t virt_image_t a01.img but all I got was: chcon: failed to change context of `a01.img' to `system_u:object_r:virt_image_t:s0': Invalid argument The host is a debian 5.0 machine.
That's the correct command to set the context for a disk image. It sounds to me like that context does not exist on your system. I'll let someone with more selinux knowledge than I have speak to how you might fix the problem. Dave
Dave Allan wrote:
Michael Kress wrote:
I've tried to set the type: chcon -t virt_image_t a01.img but all I got was: chcon: failed to change context of `a01.img' to `system_u:object_r:virt_image_t:s0': Invalid argument The host is a debian 5.0 machine.
That's the correct command to set the context for a disk image. It sounds to me like that context does not exist on your system. I'll let someone with more selinux knowledge than I have speak to how you might fix the problem.
Hi, as I'm new to debian and also to SELINUX, I was a bit lost, but reading some manuals and howtos, I found out that virt_image_t d obviously only exists in RH derivates. (I'm a CentOS addict, I should know. Lack of knowledge about SELINUX is my excuse.). So here's what I did in order to build a policy package file for kvm (i.e. kvm.pp ) and what I'd like to share with you. If you have any suggestions, please let me know. All this applies to debian 5.0, haven't tried it anywhere else. 1) I put the messages I posted before in /root/delme.txt 2) Now find out the requirements for kvm, i.e. analyze the error messages during kvm startup: audit2allow -i /root/delme.txt #============= initrc_t ============== allow initrc_t self:process execmem; #============= udev_t ============== allow udev_t etc_t:file append; (time to get rid of /root/delme.txt ..... rm /root/delme.txt ) 3) create file kvm.fc: # kvm executable will have: # label: system_u:object_r:kvm_exec_t # MLS sensitivity: s0 # MCS categories: <none> /usr/bin/kvm -- gen_context(system_u:object_r:kvm_exec_t,s0) 4) create file kvm.if: ## <summary>kvm policy</summary> ## <desc> ## <p> ## kvm policy for selinux ## </p> ## </desc> # ######################################## ## <summary> ## Execute a domain transition to run kvm. ## </summary> ## <param name="domain"> ## Domain allowed to transition. ## </param> # interface(`kvm_domtrans',` gen_require(` type kvm_t, kvm_exec_t; ') domain_auto_trans($1,kvm_exec_t,kvm_t) allow $1 kvm_t:fd use; allow kvm_t $1:fd use; allow $1 kvm_t:fifo_file rw_file_perms; allow $1 kvm_t:process sigchld; ') 5) create file kvm.te: policy_module(kvm,1.0.0) # Declarations require { type initrc_t; class process { execmem }; type udev_t; class file { append }; type etc_t; class file { append }; } type kvm_t; type kvm_exec_t; domain_type(kvm_t) domain_entry_file(kvm_t, kvm_exec_t) # kvm local policy allow initrc_t self:process execmem; allow udev_t etc_t:file append; 6) create file Makefile: # installation paths AWK ?= gawk NAME ?= $(strip $(shell $(AWK) -F= '/^SELINUXTYPE/{ print $$2 }' /etc/selinux/config)) MLSENABLED := $(shell cat /selinux/mls) ifeq ($(MLSENABLED),) MLSENABLED := 1 endif ifeq ($(MLSENABLED),1) MCSFLAG=-mcs endif ifeq ($(NAME), mls) NAME = strict MCSFLAG = -mls endif TYPE ?= $(NAME)${MCSFLAG} HEADERDIR := /usr/share/selinux/default/include include $(HEADERDIR)/Makefile 7) make 8) semodule -i kvm.pp 9) semodule -l|grep kvm kvm 1.0.0 10) virsh start myvirtualmachine Important: All has to be in one directory. You should use one directory per policy as the Makefile would compile all *.te files. Hope this helps you guys playing with selinux. Regards Michael -- Michael Kress, kress@hal.saar.de http://www.michael-kress.de / http://kress.net P E N G U I N S A R E C O O L
On Tue, Mar 03, 2009 at 09:04:19PM +0100, Michael Kress wrote:
Hi! What do I have to do to get qemu-kvm to run with selinux running with enforcing policy?
[snip]
I've tried to set the type: chcon -t virt_image_t a01.img but all I got was: chcon: failed to change context of `a01.img' to `system_u:object_r:virt_image_t:s0': Invalid argument The host is a debian 5.0 machine.
I'm not sure how it works in Debian, but I'll outline the way it does in Fedora. I believe all our SELinux policy bits for virt are in the upstream SELinux reference policy, so available to Debian too. First if you run libvirtd or qemu directly, it won't be confined at all, so you have to start from the init script. The /etc/init.d/libvirtd script is labelled with: system_u:object_r:virtd_script_exec_t:s0 With the policy transition rules, this means that when you start libvirtd via the '/etc/init.d/libvirtd start, it'll transition to unconfined_u:system_r:virtd_t:s0 $ ps -axuwfZ | grep libvirtd unconfined_u:system_r:virtd_t:s0 root 6249 0.0 0.0 65960 660 ? Sl Feb23 0:15 libvirtd --daemon Now that has libvirtd running in virtd_t domain. Next, the /usr/bin/qemu, /usr/bin/qemu-kvm and /usr/bin/qemu-system-* binaries must all be labelled system_u:object_r:qemu_exec_t:s0 When a qemu binary is launched by a program running in virtd_t, it will thus transition to system_u:system_r:qemu_t:s0 Thus QEMU is now confined. Finally, when confined, QEMU needs to access its disks, so these must all be labelled system_u:object_r:virt_image_t:s0 # ls -lZ /var/lib/libvirt/images/ -rwxr-xr-x. root root system_u:object_r:virt_image_t:s0 demo2.img This basically protects the host OS from guest VMs. With the sVirt support that was committed to libvirt yesterday, we can also now protect guest VMs from each other. What happens is that each VM runs with a dynamically generated MCS (?) level, and is thus isolated from VMs with different levels On my F11 system, you'll thus see VMs running with contexts like system_u:system_r:qemu_t:s0:c25,c100 system_u:system_r:qemu_t:s0:c231,c352 system_u:system_r:qemu_t:s0:c502,c523 system_u:system_r:qemu_t:s0:c94,c156 With disks images automatically labelled to match system_u:object_r:virt_image_t:s0:c25,c100 system_u:object_r:virt_image_t:s0:c231,c352 system_u:object_r:virt_image_t:s0:c502,c523 system_u:object_r:virt_image_t:s0:c94,c156 Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (3)
-
Daniel P. Berrange -
Dave Allan -
Michael Kress