RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 888152 - SELinux policy blocks qemu-ga's fsfreeze operation
Summary: SELinux policy blocks qemu-ga's fsfreeze operation
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.4
Hardware: Unspecified
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 831387
TreeView+ depends on / blocked
 
Reported: 2012-12-18 06:30 UTC by Qunfang Zhang
Modified: 2013-01-24 10:09 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-24 09:54:51 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Qunfang Zhang 2012-12-18 06:30:40 UTC 
Description of problem:
Install qemu-guest-agent in a rhel6.4-32 guest and start qemu-ga service, lots of commands can not be used. If start qemu-ga command manually instead of using service, the commands work.

Version-Release number of selected component (if applicable):
Host:
kernel-2.6.32-348.el6.x86_64
qemu-kvm-0.12.1.2-2.346.el6.x86_64

Guest:
kernel-2.6.32-348.el6.i686
qemu-guest-agent-0.12.1.2-2.346.el6.i686

How reproducible:
Always

Steps to Reproduce:
1. Boot a rhel6.4-32 guest
# /usr/libexec/qemu-kvm -M rhel6.4.0 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -enable-kvm -name rhel6.4-32 -uuid 255874cf-ceee-458a-b9e7-757dcf4d97bb -k en-us -rtc base=localtime,clock=host,driftfix=slew -no-kvm-pit-reinjection -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-tablet,id=input0 -drive file=/home/rhel6.4-32.qcow2,if=none,id=disk0,format=qcow2,werror=stop,rerror=stop,aio=native -device ide-drive,bus=ide.0,unit=1,drive=disk0,id=disk0  -drive file=/home/boot.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,drive=drive-ide0-1-0,bus=ide.1,unit=0,id=cdrom -netdev tap,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=44:37:E6:5E:91:5E,bus=pci.0,addr=0x5 -monitor stdio -qmp tcp:0:6666,server,nowait -chardev socket,path=/tmp/isa-serial,server,nowait,id=isa1 -device isa-serial,chardev=isa1,id=isa-serial1 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -chardev socket,id=charchannel0,path=/tmp/serial-socket,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev socket,path=/tmp/foo,server,nowait,id=foo -device virtconsole,chardev=foo,id=console0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 -spice port=5930,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -k en-us -boot c -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtserialport,bus=virtio-serial0.0,chardev=qga0,name=org.qemu.guest_agent.0 -global  PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0

2. On host:
# nc -U /tmp/qga.sock

3. Inside guest
[root@localhost ~]# service  qemu-ga start
Starting qemu-ga:                                          [  OK  ]

[root@localhost ~]# service  qemu-ga status
qemu-ga (pid  2678) is running...

   [root@localhost ~]# ps ax | grep qemu
 2678 ?        Ss     0:00 /usr/bin/qemu-ga --daemonize --method virtio-serial --path /dev/virtio-ports/org.qemu.guest_agent.0 --logfile /var/log/qemu-ga.log --pidfile /var/run/qemu-ga.pid --blacklist guest-file-open guest-file-close guest-file-read guest-file-write guest-file-seek guest-file-flush

4. Send some commands from host on step 2:
(1) {"execute":"guest-fsfreeze-status"}
{"return": "thawed"}

(2) {"execute":"guest-fsfreeze-freeze" }
{"error": {"class": "QgaCommandFailed", "desc": "Guest agent command failed, error was 'failed to freeze /, Operation not permitted'", "data": {"message": "failed to freeze /, Operation not permitted"}}}

(3) { "execute":"guest-shutdown","arguments":{"mode":"halt"}}
{"error": {"class": "UndefinedError", "desc": "An undefined error has ocurred", "data": {}}}

(4) { "execute":"guest-shutdown","arguments":{"mode":"reboot"}}
{"error": {"class": "UndefinedError", "desc": "An undefined error has ocurred", "data": {}}}

(5){ "execute":"guest-shutdown","arguments":{"mode":"powerdown"}}
{"error": {"class": "UndefinedError", "desc": "An undefined error has ocurred", "data": {}}}

(6)
{ "execute": "guest-suspend-ram"}
{"error": {"class": "Unsupported", "desc": "this feature or command is not currently supported", "data": {}}}
{ "execute": "guest-suspend-disk"}
{"error": {"class": "Unsupported", "desc": "this feature or command is not currently supported", "data": {}}}

Actual results:
1. As listed in the above step 4, these commands do not work. This is unexpected.
2. As in step 2, "guest-file-*" are blacklisted if start qemu-ga service, so all "guest-file-*" do not work, this is expected.

Expected results:
The commands in step 4 should work well.

Additional info:
(1) I tried rhel6.4-64 guest with same steps, rhel6.4-64 guest works well for all the above commands in step 4.

(2) If do NOT start qemu-ga service, start qemu-ga with the following command manually, the issue does NOT exist.
(The command is the same as the background command when starting qemu-ga service)
#qemu-ga --daemonize --method virtio-serial --path /dev/virtio-ports/org.qemu.guest_agent.0 --logfile /var/log/qemu-ga.log --pidfile /var/run/qemu-ga.pid --blacklist guest-file-open guest-file-close guest-file-read guest-file-write guest-file-seek guest-file-flush
Comment 2 Luiz Capitulino 2013-01-07 16:35:45 UTC 
That's bizarre. Your description seems to indicate that the problem lies in the init script _or_ it's making use of some qemu-ga command-line parameter that could cause trigger bug.

Jeff is getting overloaded with qemu-ga bugs for Windows, so I'll take this over to help him.
Comment 4 Luiz Capitulino 2013-01-09 01:44:38 UTC 
Can you please check with what user ID the process is running when started by the script? This can be checked with ps.
Comment 5 Luiz Capitulino 2013-01-09 01:45:57 UTC 
Dropping NEEDINFO request. Talked with Ademar today and we have to investigate this issue.
Comment 6 Luiz Capitulino 2013-01-09 18:59:07 UTC 
This bug has the potential of being a blocker. Please, read carefully what I'll report and the information I'll ask for.

I've debugged this and turns out it's SELinux related, most likely related to the newly added qemu-ga policy (bug 839831).

I've installed a fresh VM with latest RHEL-6.4 (today's compose). Here's relevant versions:

kernel-2.6.32-350.el6.i686
qemu-guest-agent-0.12.1.2-2.349.el6.i686
selinux-policy-3.7.19-191.el6.noarch

I've tested all the commands Qunfang has tested. In my testing, guest-shutdown, guest-suspend-ram and guest-suspend-disk work; guest-fsfreeze-freeze does not. It fails as reported by Qunfang. That is, the FSFREEZE ioctl() fails.

Now, if I do:

# echo 0 > /selinux/enforce

The guest-fsfreeze-freeze command _does_ work.

Qunfang, could you please:

1. Provide the version of the selinux-policy package of the VM where you got your initial results
2. If it's lower than selinux-policy-3.7.19-191, then please update to the latest one and re-run all tests, so that we can confirm that we're getting the same behavior
3. Install latest RHEL-6.4 on a x86_64 guest and report whether or not the behavior is the same (make selinux is enabled and versions match)

I'd guess the behavior is the same no matter the arch, but you didn't get it on x86_64 because of selinux version or setup.
	
Miroslav, please check the policy looking for why FSFREEZE would fail.

If this is really a bug in our policy and if it happens no matter the arch, then I'd vote for this as being a blocker as this is a regression and file-system freeze is one of qemu-ga's most important features.
Comment 7 Luiz Capitulino 2013-01-09 20:13:25 UTC 
Just confirmed it also happens on x86_64 (item 3 above).
Comment 8 Miroslav Grepl 2013-01-09 21:05:51 UTC 
Are you getting AVC msgs?
Comment 9 Qunfang Zhang 2013-01-10 02:57:32 UTC 
(In reply to comment #6)
> This bug has the potential of being a blocker. Please, read carefully what
> I'll report and the information I'll ask for.
> 
> I've debugged this and turns out it's SELinux related, most likely related
> to the newly added qemu-ga policy (bug 839831).
> 
> I've installed a fresh VM with latest RHEL-6.4 (today's compose). Here's
> relevant versions:
> 
> kernel-2.6.32-350.el6.i686
> qemu-guest-agent-0.12.1.2-2.349.el6.i686
> selinux-policy-3.7.19-191.el6.noarch
> 
> I've tested all the commands Qunfang has tested. In my testing,
> guest-shutdown, guest-suspend-ram and guest-suspend-disk work;
> guest-fsfreeze-freeze does not. It fails as reported by Qunfang. That is,
> the FSFREEZE ioctl() fails.
> 
> Now, if I do:
> 
> # echo 0 > /selinux/enforce
> 
> The guest-fsfreeze-freeze command _does_ work.
> 
> Qunfang, could you please:
> 
> 1. Provide the version of the selinux-policy package of the VM where you got
> your initial results

Hi, Luiz
In the last round fo qemu-ga function test, the selinux-policy version is selinux-policy-3.7.19-185.el6.noarch, the selinux-policy related bugs were not fixed at that time. We could have a re-test soon with latest qemu-kvm and selinux-policy to confirm your following questions. 

Thanks,Qunfang

> 2. If it's lower than selinux-policy-3.7.19-191, then please update to the
> latest one and re-run all tests, so that we can confirm that we're getting
> the same behavior
> 3. Install latest RHEL-6.4 on a x86_64 guest and report whether or not the
> behavior is the same (make selinux is enabled and versions match)
> 
> I'd guess the behavior is the same no matter the arch, but you didn't get it
> on x86_64 because of selinux version or setup.
> 	
> Miroslav, please check the policy looking for why FSFREEZE would fail.
> 
> If this is really a bug in our policy and if it happens no matter the arch,
> then I'd vote for this as being a blocker as this is a regression and
> file-system freeze is one of qemu-ga's most important features.
Comment 10 Luiz Capitulino 2013-01-10 19:03:47 UTC 
Miroslav, you'll find the avc messages (after issuing guest-fsfreeze-freeze) below.

But I'm honestly wondering if we should just revert the whole thing. Is it possible? (please, don't do it yet, I'm still checking if we should do it).

[root@rhel64 ~]# ausearch -m avc -ts recent
----
time->Thu Jan 10 17:00:36 2013
type=SYSCALL msg=audit(1357844436.012:32): arch=c000003e syscall=16 success=no exit=-13 a0=7 a1=c0045877 a2=0 a3=1 items=0 ppid=1 pid=1211 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="qemu-ga" exe="/usr/bin/qemu-ga" subj=unconfined_u:system_r:virt_qemu_ga_t:s0 key=(null)
type=AVC msg=audit(1357844436.012:32): avc:  denied  { write } for  pid=1211 comm="qemu-ga" path="/" dev=dm-0 ino=2 scontext=unconfined_u:system_r:virt_qemu_ga_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir
----
time->Thu Jan 10 17:00:36 2013
type=SYSCALL msg=audit(1357844436.013:33): arch=c000003e syscall=16 success=no exit=-13 a0=7 a1=c0045878 a2=0 a3=3 items=0 ppid=1 pid=1211 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="qemu-ga" exe="/usr/bin/qemu-ga" subj=unconfined_u:system_r:virt_qemu_ga_t:s0 key=(null)
type=AVC msg=audit(1357844436.013:33): avc:  denied  { write } for  pid=1211 comm="qemu-ga" path="/" dev=dm-0 ino=2 scontext=unconfined_u:system_r:virt_qemu_ga_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir
----
time->Thu Jan 10 17:00:36 2013
type=SYSCALL msg=audit(1357844436.013:34): arch=c000003e syscall=2 success=no exit=-13 a0=7f565e6daf50 a1=80000 a2=0 a3=3 items=0 ppid=1 pid=1211 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="qemu-ga" exe="/usr/bin/qemu-ga" subj=unconfined_u:system_r:virt_qemu_ga_t:s0 key=(null)
type=AVC msg=audit(1357844436.013:34): avc:  denied  { read } for  pid=1211 comm="qemu-ga" name="/" dev=usbfs ino=8186 scontext=unconfined_u:system_r:virt_qemu_ga_t:s0 tcontext=system_u:object_r:usbfs_t:s0 tclass=dir
----
time->Thu Jan 10 17:00:36 2013
type=SYSCALL msg=audit(1357844436.013:35): arch=c000003e syscall=2 success=no exit=-13 a0=7f565e6dabf0 a1=80000 a2=0 a3=3 items=0 ppid=1 pid=1211 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="qemu-ga" exe="/usr/bin/qemu-ga" subj=unconfined_u:system_r:virt_qemu_ga_t:s0 key=(null)
type=AVC msg=audit(1357844436.013:35): avc:  denied  { read } for  pid=1211 comm="qemu-ga" name="/" dev=vda1 ino=2 scontext=unconfined_u:system_r:virt_qemu_ga_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir
[root@rhel64 ~]#
Comment 11 Luiz Capitulino 2013-01-10 19:08:34 UTC 
(In reply to comment #9)

> In the last round fo qemu-ga function test, the selinux-policy version is
> selinux-policy-3.7.19-185.el6.noarch, the selinux-policy related bugs were
> not fixed at that time. We could have a re-test soon with latest qemu-kvm
> and selinux-policy to confirm your following questions. 

Thanks Qunfang. I think it's not needed to re-test this issue because I've tested it myself already. Now, it would be very nice to do a full qemu-ga testing with latest & fresh RHEL-6.4 install so that we can double check that only fsfreeze isn't working.
Comment 12 Miroslav Grepl 2013-01-11 09:10:17 UTC 
Could you also test fsfreeze with permissive. I would like to see why 

----
time->Thu Jan 10 17:00:36 2013
type=SYSCALL msg=audit(1357844436.012:32): arch=c000003e syscall=16 success=no exit=-13 a0=7 a1=c0045877 a2=0 a3=1 items=0 ppid=1 pid=1211 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="qemu-ga" exe="/usr/bin/qemu-ga" subj=unconfined_u:system_r:virt_qemu_ga_t:s0 key=(null)
type=AVC msg=audit(1357844436.012:32): avc:  denied  { write } for  pid=1211 comm="qemu-ga" path="/" dev=dm-0 ino=2 scontext=unconfined_u:system_r:virt_qemu_ga_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir
----

is needed. What is "qemu-ga" trying to write to "/"?
Comment 13 Luiz Capitulino 2013-01-11 12:38:22 UTC 
(In reply to comment #12)
> Could you also test fsfreeze with permissive.

I thought that's what I did in comment 10, that is:

1. # echo 0 > /selinux/enforce
2. run qemu-ga's guest-fsfreeze-freeze command

Or do you mean something else?

> I would like to see why 
> 
> ----
> time->Thu Jan 10 17:00:36 2013
> type=SYSCALL msg=audit(1357844436.012:32): arch=c000003e syscall=16
> success=no exit=-13 a0=7 a1=c0045877 a2=0 a3=1 items=0 ppid=1 pid=1211
> auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=2 comm="qemu-ga" exe="/usr/bin/qemu-ga"
> subj=unconfined_u:system_r:virt_qemu_ga_t:s0 key=(null)
> type=AVC msg=audit(1357844436.012:32): avc:  denied  { write } for  pid=1211
> comm="qemu-ga" path="/" dev=dm-0 ino=2
> scontext=unconfined_u:system_r:virt_qemu_ga_t:s0
> tcontext=system_u:object_r:root_t:s0 tclass=dir
> ----
> 
> is needed. What is "qemu-ga" trying to write to "/"?

That's indeed a good question. qemu-ga will opens "/" (and FSs it freezes) as O_RDONLY and then issues the FIFREEZE ioctl. It's the ioctl() that fails.
Comment 14 Luiz Capitulino 2013-01-11 13:11:52 UTC 
Another interesting info is that, as reported by Qunfang, the denial only happens when starting qemu-ga with 'service qemu-ga start', if you start it by hand fsfreeze just works.

I took a quick look at the init scripts and couldn't spot anything that could cause this though.
Comment 15 Miroslav Grepl 2013-01-11 13:24:08 UTC 
Well, I see

"success=no"

it means it was denied.

Please run

# setenforce 0

and re-test it.

If you run it by hand, then the service runs as unconfined_t instead of virt_qemu_ga_t.
Comment 16 Luiz Capitulino 2013-01-11 13:30:05 UTC 
Here you go, less messages this time:

# setenforce 0
# service qemu-ga start
(run fsfreeze on another terminal, it works)

[root@rhel64 ~]# ausearch -m avc -ts recent
----
time->Fri Jan 11 11:27:54 2013
type=AVC msg=audit(1357910874.112:36): avc:  denied  { write } for  pid=1204 comm="qemu-ga" path="/" dev=dm-0 ino=2 scontext=unconfined_u:system_r:virt_qemu_ga_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir
[root@rhel64 ~]#
Comment 38 Luiz Capitulino 2013-01-16 11:55:21 UTC 
You shouldn't close this bz. Bug 839831 is about adding the policy (which has already happened) and this one is a real bug. What will you do for bugs in the future for example? Close them all as a duplicate of bug 839831?
Note You need to log in before you can comment on or make changes to this bug.