Bug 1257893 - Guests on Fedora22 Xen host are able to write to read-only disks with full device emulation type.
Guests on Fedora22 Xen host are able to write to read-only disks with full de...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
22
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Michael Young
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: CVE-2015-7311/xsa142
  Show dependency treegraph
 
Reported: 2015-08-28 06:41 EDT by Lin Liu
Modified: 2016-04-12 22:19 EDT (History)
9 users (show)

See Also:
Fixed In Version: 4.5.1-8.fc23 xen-4.4.3-3.fc21 xen-4.5.1-8.fc22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-04-12 22:19:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lin Liu 2015-08-28 06:41:36 EDT
Description of problem:
Creating guests with read-only (r) flag on disks, data can be written to the read-only disks with full device emulation type. Creating guests with read-only flag on disk using virtual block device mode, writing to disk will be blocked.

Version-Release number of selected component (if applicable):
xen-hypervisor-4.5.1-6.fc22.x86_64
xen-4.5.1-6.fc22.x86_64
kernel-4.0.4-301.fc22.x86_64


How reproducible:
always

Steps to Reproduce:
1.  Create a RHEL7.2 guest on Fedora22 Xen, with the configure file including below lines:
    disk = [ "file:/root/RHEL-Server-7.2-64-hvm.raw,xvda,w","file:/root/test1.img,hdb,r","file:/root/test2.img,xvdc,r" ]
2.  Login to guest and check the disks display:
    # ls /dev/sd*
    /dev/sda  /dev/sda1  /dev/sda2  /dev/sdb  /dev/sdc

    # ls /dev/xvd*
    /dev/xvda  /dev/xvda1  /dev/xvda2  /dev/xvdc

3.  Format disk /dev/sdb, /dev/sdc and /dev/xvdc or dd some data to the disks.

Actual results:

For disk /dev/sdb using full device emulation type, formatting or writing data isn't blocked by the read-only flag in configuration file when creating the guest.  
For disk /dev/sdc or /dev/xvdc (Actually they are the same disk, but using different virtualization types), actual results are different:
Using full device emulation type, /dev/sdc can be formatted or written data:
[root@dhcp-8-159 ~]# mkfs.ext4 /dev/sdc
mke2fs 1.42.9 (28-Dec-2013)
/dev/sdc is entire device, not just one partition!
Proceed anyway? (y,n) y
Discarding device blocks: done
...
...
Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

[root@dhcp-8-159 ~]# dd if=/dev/zero of=/dev/sdc bs=1 count=10
10+0 records in
10+0 records out
10 bytes (10 B) copied, 0.005907 s, 1.7 kB/s

Using virtual block device mode, formatting or writing data to /dev/xvdc will be blocked:
[root@dhcp-8-159 ~]# mkfs.ext4 /dev/xvdc
mke2fs 1.42.9 (28-Dec-2013)
/dev/xvdc: Operation not permitted while setting up superblock

[root@dhcp-8-159 ~]# dd if=/dev/zero of=/dev/xvdc bs=1 count=10
dd: error writing ‘/dev/xvdc’: Operation not permitted
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.0107866 s, 0.0 kB/s

Expected results:
Writing data to read-only disks should be failed on disks with both full-virt and para-virt types.  

Additional info:
none
Comment 1 Michael Young 2015-09-07 15:04:17 EDT
I can't reproduce this. I don't have access to the hvm image are using, so do you know what in it is creating the /dev/sd* disks? I don't get them (launching the guest via xl) unless I specify them as sd disks in the configuration file.
Comment 2 Lin Liu 2015-09-08 03:12:02 EDT
Hi Michael,

Please create the hvm guest with this configuration:

disk = [ "file:/root/RHEL-Server-7.2-64-hvm.raw,xvda,w","file:/root/test1.img,hdb,r","file:/root/test2.img,xvdc,r" ]

xvda is the hvm image and hdb and xvdc are readonly disks with different virtul type.

If you still get problem, please check the kernel parameter of guest, make sure there is no xen_emul_unplug in kernel.

Thank you!
Lin Liu
Comment 3 Fedora Update System 2015-09-15 15:45:43 EDT
xen-4.5.1-8.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15943
Comment 4 Fedora Update System 2015-09-15 16:08:06 EDT
xen-4.5.1-8.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15944
Comment 5 Fedora Update System 2015-09-15 17:03:45 EDT
xen-4.4.3-3.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15946
Comment 6 Fedora Update System 2015-09-16 00:52:40 EDT
xen-4.5.1-8.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update xen'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15943
Comment 7 Fedora Update System 2015-09-16 21:02:08 EDT
xen-4.4.3-3.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update xen'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15946
Comment 8 Fedora Update System 2015-09-16 21:05:49 EDT
xen-4.5.1-8.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update xen'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15944
Comment 9 Lin Liu 2015-09-17 05:32:46 EDT
This bug is fixed with xen-4.5.1-8.fc22.x86_64, when creating guest with read-only disks, boot guest failed with error message:

1. Creating guest with read-only IDE disk:
[root@dhcp-66-73-92 ~]# cat xen-7-client.cfg | grep disk
disk = [ "file:/root/RHEL-Server-7.2-64-20150910.2-hvm.raw,xvda,w","file:/root/test1.img,hdb,r","file:/root/test2.img,xvdc,w" ]

[root@dhcp-66-73-92 ~]# xl create xen-7-client.cfg
Parsing config from xen-7-client.cfg
WARNING: you seem to be using "kernel" directive to override HVM guest firmware. Ignore that. Use "firmware_override" instead if you really want a non-default firmware
WARNING: ignoring device_model directive.
WARNING: Use "device_model_override" instead if you really want a non-default device_model
libxl: error: libxl_dm.c:806:libxl__build_device_model_args_new: qemu-xen doesn't support read-only disk drivers
libxl: error: libxl_dm.c:1504:device_model_spawn_outcome: (null): spawn failed (rc=-3)
libxl: error: libxl_create.c:1322:domcreate_devmodel_started: device model did not start: -3
libxl: error: libxl_dm.c:1600:kill_device_model: unable to find device model pid in /local/domain/13/image/device-model-pid
libxl: error: libxl.c:1608:libxl__destroy_domid: libxl__destroy_device_model failed for 13
libxl: info: libxl.c:1691:devices_destroy_cb: forked pid 3489 for destroy of domain 13



2. Creating guest with read-only disk using pv drivers:
[root@dhcp-66-73-92 ~]# cat xen-7-client.cfg | grep disk
disk = [ "file:/root/RHEL-Server-7.2-64-20150910.2-hvm.raw,xvda,w","file:/root/test1.img,hdb,w","file:/root/test2.img,xvdc,r" ]
[root@dhcp-66-73-92 ~]# xl create xen-7-client.cfg
Parsing config from xen-7-client.cfg
WARNING: you seem to be using "kernel" directive to override HVM guest firmware. Ignore that. Use "firmware_override" instead if you really want a non-default firmware
WARNING: ignoring device_model directive.
WARNING: Use "device_model_override" instead if you really want a non-default device_model
libxl: error: libxl_dm.c:806:libxl__build_device_model_args_new: qemu-xen doesn't support read-only disk drivers
libxl: error: libxl_dm.c:1504:device_model_spawn_outcome: (null): spawn failed (rc=-3)
libxl: error: libxl_create.c:1322:domcreate_devmodel_started: device model did not start: -3
libxl: error: libxl_dm.c:1600:kill_device_model: unable to find device model pid in /local/domain/14/image/device-model-pid
libxl: error: libxl.c:1608:libxl__destroy_domid: libxl__destroy_device_model failed for 14
libxl: info: libxl.c:1691:devices_destroy_cb: forked pid 3562 for destroy of domain 14


For the second case: Creating guest with read-only disk using pv drivers, is the actual result expected? I think the guest should be boot and xdc disk cannot be written is the expected result as before.
qemu-xen should not support read-only disk drivers with full emulation type, but for pv drivers, guest with read-only disk with pv drivers should be boot.
Comment 10 Michael Young 2015-09-19 14:01:08 EDT
(In reply to Lin Liu from comment #9)
> For the second case: Creating guest with read-only disk using pv drivers, is
> the actual result expected? I think the guest should be boot and xdc disk
> cannot be written is the expected result as before.
> qemu-xen should not support read-only disk drivers with full emulation type,
> but for pv drivers, guest with read-only disk with pv drivers should be boot.

The problem with this is (in my testing at least) that you can write to the scsi version of the disk if you boot the guest with xen_emul_unplug=never , so it makes sense to force the disk to be read only in qemu so a malicious guest can't arrange to write to it.
Comment 11 Fedora Update System 2015-09-21 06:48:11 EDT
xen-4.5.1-8.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 12 Fedora Update System 2015-09-26 17:50:04 EDT
xen-4.4.3-3.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Comment 13 Fedora Update System 2015-09-26 23:22:21 EDT
xen-4.5.1-8.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Comment 14 Lin Liu 2016-04-11 03:59:49 EDT
This bug still can be reproduced on xen-4.6.1-5.fc24, steps are the same with the description of this bug. So reopen it.
Comment 15 Michael Young 2016-04-11 16:56:21 EDT
I can't reproduce this. Can you give more details of your set up please?
Comment 16 Lin Liu 2016-04-12 01:43:59 EDT
(In reply to Michael Young from comment #15)
> I can't reproduce this. Can you give more details of your set up please?

Hi Michael, 

Sorry for my mistake. The bug is fixed in version xen-4.6.1-5.fc24, I confused the error message when editing a file in the read-only disk and thought this file could be edited. And I checked the source rpm the patch ([XSA-142, CVE-2015-7311] (#1257893)) for this bug isn't included in SOURCES, so I thought this fix in xen-4.5.1-8  was missing in the new version xen-4.6.1. Today I retest this bug, the read-only disk cannot be able to write actually. I will close this bug then.

And I have a question, for this bug, the upstream xen-4.6.1 has fixed this, so the fedora patch XSA-142 wasn't included in xen-4.6.1-5.fc24, am I right?
My question is, could you please tell me the detailed fedora xen build process? Such as, when upstream release a new version, you will compare the fedora patches with the upstream source, if the fedora patches are included in the source, the patches will be dropped, or the left fedora patches are all introduced to the fedora xen new version, is my guess right? Since I checked the xen-4.6.1-5.fc24 changelog, there are many bug fix patches, but in the SPEC and SOURCES, can only find few patches. I guess the others patches were already included in upstream xen-4.6.1.

Thank you!

Br,
Lin liu
Comment 17 Michael Young 2016-04-12 16:37:23 EDT
A later version of xen will contain most or all security patches up to that point, so naturally I remove the security patches and any other patches that are included in the new upstream source.
Comment 18 Lin Liu 2016-04-12 22:19:17 EDT
(In reply to Michael Young from comment #17)
> A later version of xen will contain most or all security patches up to that
> point, so naturally I remove the security patches and any other patches that
> are included in the new upstream source.

Got it, thank you very much. I close this bug.

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