Xen Security Issue Patched

An anonymous reader sends in word of a privilege escalation security issue identified in the open source Xen hypervisor. Xen has issued a hotfix and urged all users to install it. The problem was disclosed by Secunia last week. A user of a guest domain with root privileges could execute arbitrary commands in domain 0 via specially crafted entries in grub.conf when the guest system is booted.

Comments

why would a domU have grub anyway?

[myowntrueself]

A paravirtualised domU does not need a boot loader and does not even have access to its own kernel. Which is nice because you can give it an unmodular kernel which is more secure in as much as a user on that domU cannot load their own (potentially exploiting) kernel modules.

Its only an HVM domU that would need a boot loader and its own kernel.

I've read through TFA and the Xen mailing list and I can't see anything that says whether this affects both paravirtualised *and* HVM or just one or the other...?

In the case of paravirtualised, why on earth would the creating the domU even *look* for a /boot/grub/grub.conf in the domU filesystem?? Makes no sense at all.

Avoid PyGrub and everything is fine

[Russell Coker]

PyGrub expects that the root device is partitioned and searches on partition 1 for the GRUB configuration. This is bad because it requires you to have a partition table which makes things inconvenient if you want to resize the disk space provided to the virtual machine.

I run my Xen DomU's with a single virtual disk per filesystem, no partition tables (the DomU mounts /dev/vbda or /dev/hda etc) and I can easily resize any filesystem at any time by stopping the DomU, extending the LVM volume, and extending the filesystem.

This doesn't work with PyGrub, I could fix the bug but I haven't bothered - it's easier to just have the kernel and initrd stored outside the filesystem managed by the DomU.

This configuration makes it easier to manage (one kernel and initrd for multiple DomU's) and avoids security issues with PyGrub.