Bug 670258 - Miscellaneous selinux problems running libguestfs in RHEL 6.1
Summary: Miscellaneous selinux problems running libguestfs in RHEL 6.1
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.1
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: rc
: ---
Assignee: Daniel Walsh
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-17 17:18 UTC by Richard W.M. Jones
Modified: 2012-03-08 18:45 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-01-26 21:37:49 UTC
Target Upstream Version:


Attachments (Terms of Use)
Extract from audit.log (3.74 KB, text/plain)
2011-01-17 17:18 UTC, Richard W.M. Jones
no flags Details

Description Richard W.M. Jones 2011-01-17 17:18:12 UTC
Created attachment 473898 [details]
Extract from audit.log

Description of problem:

The attached audit.log is an extract from running the
SELinux in permissive mode whilst running the command
as NON-root:

guestfish -a win2003.iso --ro -m /dev/sda

Version-Release number of selected component (if applicable):

libguestfs-1.7.17-9.el6.x86_64
selinux-policy-targeted-3.7.19-54.el6_0.3.noarch
selinux-policy-3.7.19-54.el6_0.3.noarch

Comment 1 Richard W.M. Jones 2011-01-17 17:21:10 UTC
audit2allow is suggesting:

#============= qemu_t ==============
allow qemu_t boot_t:file { read getattr open };
allow qemu_t unconfined_t:unix_stream_socket connectto;
allow qemu_t user_tmp_t:file { read ioctl open };
allow qemu_t user_tmp_t:sock_file write;

Comment 2 Richard W.M. Jones 2011-01-17 17:22:58 UTC
libguestfs works by running the following qemu-kvm command.
The command is generated and may be slightly different
each time.

/usr/libexec/qemu-kvm \
    -drive file=en_win_srv_2003_r2_enterprise_with_sp2_cd1_X13-05460.iso,snapshot=on,if=virtio \
    -nodefconfig \
    -enable-kvm \
    -nodefaults \
    -nographic \
    -m 500 \
    -no-reboot \
    -device virtio-serial \
    -serial stdio \
    -chardev socket,path=/tmp/libguestfsxJgTAK/sock,id=channel0 \
    -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \
    -kernel /tmp/.guestfs-500/kernel.5197 \
    -initrd /tmp/.guestfs-500/initrd.5197 \
    -append 'panic=1 console=ttyS0 udevtimeout=300 noapic acpi=off printk.time=1 cgroup_disable=memory selinux=0 guestfs_verbose=1 TERM=xterm ' \
    -drive file=/tmp/.guestfs-500/root.5197,snapshot=on,if=virtio,cache=writeback

Comment 3 Daniel Walsh 2011-01-17 19:08:50 UTC
I think it is probably better to turn the transition off to a confined qemu.

# setsebool -P allow_unconfined_qemu_transition 0

We really do not use this confinement much since we have moved to svirt confinement.

Comment 4 Richard W.M. Jones 2011-01-17 19:56:11 UTC
(In reply to comment #3)
> I think it is probably better to turn the transition off to a confined qemu.
> 
> # setsebool -P allow_unconfined_qemu_transition 0
> 
> We really do not use this confinement much since we have moved to svirt
> confinement.

Is this a suggestion that you want me to try out?

I think on this system I changed this setting.  Currently
it is set to:

$ getsebool allow_unconfined_qemu_transition
allow_unconfined_qemu_transition --> on

Comment 5 Daniel Walsh 2011-01-17 20:47:09 UTC
Yes I want you to turn it off.  Therefore qemu will run under the unconfined domain.

Comment 6 Richard W.M. Jones 2011-01-17 20:55:28 UTC
That fixes the problem.  However I'm fairly sure I turned
this boolean on before for a reason, although I can't recall
what it was now.  I guess I'll wait to see if anything breaks.


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