pyGrub bootloader used to boot Xen para-virtualized guests did not have support for password command as supported by normal grub. If this option was used in grub.conf, it did not restrict users with access to para-virtualized guest's console from booting guest or changing kernel boot parameters without providing configured password. This could allow user with access to VMs console to get root privileges on the guest's operating system. Upstream patches: ----------------- http://xenbits.xensource.com/xen-unstable.hg?rev/8f783adc0ee3 http://xenbits.xensource.com/staging/xen-unstable.hg?rev/a28c9c2fa8de http://xenbits.xensource.com/xen-unstable.hg?rev/e513d565c8f1 http://xenbits.xensource.com/xen-unstable.hg?rev/67f1b8b32585 http://xenbits.xensource.com/xen-unstable.hg?rev/168f0cfeded0 CVE Request: ------------ http://www.openwall.com/lists/oss-security/2009/09/25/1
Steps to Reproduce (taken from BZ#518124): ------------------------------------------ xm create -c guest press space bar to stop the grub count down press e to edit select the kernel line and press e Append a "1" to the end of the kernel line and press return press "b" to boot Actual results: System boot to init 1 Expected results: Pygrub prompt should request a password when you attempt to edit grub during boot. Additional info: grub.conf file contents: default=0 timeout=5 password --md5 ********************* splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux Server (2.6.18-128.el5xen) root (hd0,0) kernel /vmlinuz-2.6.18-128.el5xen ro root=/dev/vg/djc2bdb_rootvg/djc2bdb_roo otlv console=tty0 console=xvc0 initrd /initrd-2.6.18-128.el5xen.img
This issue affects latest versions of xen package, as shipped with Fedora releases of 10 and 11 (xen-3.3.0-1.fc10 and xen-3.3.1-11.fc11). Please fix.
This technically is an enhancement, but it was decided to tag this as security, as pyGrub does not come with documentation explaining which configuration commands of the (real) grub are supported. Users therefore expect it to support all commands recognized by normal grub and expecting password setting to be enforced by pyGrub too.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2009:1472 https://rhn.redhat.com/errata/RHSA-2009-1472.html
(In reply to comment #3) > This technically is an enhancement, but it was decided to tag this as security, > as pyGrub does not come with documentation explaining which configuration > commands of the (real) grub are supported. Users therefore expect it to > support all commands recognized by normal grub and expecting password setting > to be enforced by pyGrub too. Hm, I just saw this now, and I have to say that it is very, very odd that this is tagged as security. The pygrub password protection feature provides absolutely no security at all. In point of fact, due to the architecture of pygrub, it can't. All pygrub does is run as a process on dom0, loopback mount the image file the contains the guest disk, extract the kernel and initrd, and then boot the guest from that kernel+initrd. Adding password protection to pygrub disables this pretty grub-like interface, but there is nothing at all that prevents a user from doing the same loopback mounting steps by hand and booting the kernel that way. It's not even preventable using user/groups (instead of root, for instance), since by definition a user must have access to a guest hard drive image in order to boot it. So why do we think this is a security issue? Chris Lalancette
Hello Jan, Chris, "This could allow user with access to VMs console to get root privileges on the guest's operating system." Do you mean Xen's xm console? So this is security risk or no?
(In reply to comment #10) > Hello Jan, Chris, > > "This could allow user with access to VMs console to get > root privileges on the guest's operating system." > > Do you mean Xen's xm console? > > So this is security risk or no? This is not a security risk. It may increase security a little but like Chris stated in comment #7 I don't think is a security issue. Let me clarify the situation: For PV guests the pygrub is run before the actual domain boot - it extracts the kernel and initrd files from the VM image. It always allowed you to choose the image and/or edit kernel line before booting. This line was then passed to the PV guest and booted. You were able to edit the kernel line to pass init 1 parameter there to boot to single user mode. This patch is adding option to read 'password' field in /boot/grub/grub.conf file and require password for this kind of changes like editing kernel lines - this *may* increase security a little from this point of view but not from the other. You can always mount an image file as a loopback device and edit the /boot/grub/grub.conf manually. Of course, you have to be root to do that but when you try to run a PV guest using 'xm create -c PVguest' you have to be root as well so how does it increase security then? Michal
Fedora 14 (xen-4.0.1) has this change, so I'm going to close this bug as now Red Hat Enterprise Linux 5 and latest Fedora have this. It does not look like Fedora 13 has the changes, however the above comments indicate that this is more a security enhancement than a fix.