Bug 1670790

Summary: virt-builder cannot build images on platforms that does not provide read-access to system kernel images for non-root users
Product: [Community] Virtualization Tools Reporter: Jarl Friis <jarl>
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED NOTABUG QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: ptoscano, tburke
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-01-30 11:41:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jarl Friis 2019-01-30 11:21:37 UTC
Description of problem:

One of the fundamental values of virt-builder is that it does not require root privileges, that is state in the man page (http://libguestfs.org/virt-builder.1.html) as "nothing requires root privileges"

However the current design/implementation has a prerequisite condition on the platform it is installed/running on. virt-builder requires that system kernel images are readable by non-root user. This prerequisite is not true for Debian and Ubuntu (and maybe others), hence the virt-builder does not work on these platforms. If Debian and Ubuntu should continue to be "supported" target platforms (and I suggest they should) then a change is needed for virt-builder.

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


How reproducible:
Every time!


Steps to Reproduce:
1. $ LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 virt-builder ubuntu-18.04

Actual results:
It fails with the following relevant output:
cp: cannot open '/boot/vmlinuz-4.18.0-13-generic' for reading: Permission denied
supermin: cp -p '/boot/vmlinuz-4.18.0-13-generic' '/var/tmp/.guestfs-1000/appliance.d.pqks7vg3/kernel': command failed, see earlier errors
libguestfs: trace: launch = -1 (error)
virt-builder: error: libguestfs error: /usr/bin/supermin exited with error 
status 1, see debug messages above

Expected results:
That an image named ubuntu-18.04.img was built.

Workaround:
Run the command with sudo.

Proposals for resolution:
Both proposals is an implementation of the idea of removing the prerequisite that a non-user has read access to system kernels. 

1) Ship the kernel image(s) that are needed in the file that is downloaded anyway, i.e. http://libguestfs.org/download/builder/ubuntu-18.04.xz and use these instead of the kernels found on the OS.

2) Make a small helper program with SUID that reads the kernel image and use that program for that purpose only.

Additional info:
There is a bug report on the ubuntu package on https://bugs.launchpad.net/bugs/1813662 however I do not consider this issue a packaging problem. I think the issues should be resolved at it's roots, removing the requirement on the OS that the users has read-access to system kernel images.

Comment 1 Richard W.M. Jones 2019-01-30 11:41:48 UTC
This is a bug in Ubuntu, please see my and Hilko's extensive comments in
https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1813662
I have nothing more to add.

Comment 2 Pino Toscano 2019-01-30 11:43:05 UTC
(In reply to Jarl Friis from comment #0)
This prerequisite is not true
> for Debian and Ubuntu (and maybe others), hence the virt-builder does not
> work on these platforms. If Debian and Ubuntu should continue to be
> "supported" target platforms (and I suggest they should) then a change is
> needed for virt-builder.

Note that on Debian the vmlinuz files of the kernels have normal permissions (readable by anyone).
This problem is specific to Ubuntu (and its derivatives).

> 1) Ship the kernel image(s) that are needed in the file that is downloaded
> anyway, i.e. http://libguestfs.org/download/builder/ubuntu-18.04.xz and use
> these instead of the kernels found on the OS.

Not doable, as you do not want to run an arbitrary kernel in an untrusted guest.

> 2) Make a small helper program with SUID that reads the kernel image and use
> that program for that purpose only.

Please do take a look at our documentation:
http://libguestfs.org/guestfs.3.html
http://libguestfs.org/guestfs-internals.1.html (especially this)
http://libguestfs.org/guestfs-faq.1.html

The documentation should explain why the approach (1) you suggested cannot work.
The approach (2) would be a workaround possibly worse than the problem itself; not to mention all the possible security issues of writing a suid binary, where code issues could cause bad CVEs.

> There is a bug report on the ubuntu package on
> https://bugs.launchpad.net/bugs/1813662 however I do not consider this issue
> a packaging problem. I think the issues should be resolved at it's roots,
> removing the requirement on the OS that the users has read-access to system
> kernel images.

That bug shows also how other packages were impacted by the change of permissions of the kernels.
Considering that no other distro opted for this "security solution", and that it can be easily worked around in other ways, this is definitely an Ubuntu breakage.

Comment 3 Jarl Friis 2019-01-31 12:39:27 UTC
@Pino: Thanks for emphasizing that only Ubuntu (and derivatives) is affected. I should have researched myself, sorry.

Thank you for feedback on my ideas on solving the problem, I can see that change in libguestfs funcitonality is more complex than I thought. At least my ideas have now been reviewed by the right people.

I completely agree with you that idea 2; a suid binary is not a good
idea. I will read up the technical documentation to understand the
problems with idea 1, thanks.

@maintainers (hereamong Richard Jones):

I understand that you have requested a change (revert) in the linux package on ubuntu so read permission is not restricted to root user (https://bugs.launchpad.net/bugs/759725) as this has broken the libguestfs functionality on ubuntu.
I also understand that there is no real security reasons for restricting read-access to the system kernels.

However it seems that the kernel maintainers are still decided to not
open up for read-permission on kernel images (rationally or not). To
help users (those who compile and install them self) know what they
need to do in order to make it work on ubuntu I wonder if it was worth
adding these steps (change file permission on kernel images) in the
documentation.  It could be added on
http://libguestfs.org/guestfs-building.1.html. Either in section
"BUILDING FROM TARBALLS" or "INSTALLING" and eventually mention that
this is due to the bug https://bugs.launchpad.net/bugs/759725 that you
have reported. Maybe even better to actually perform this file
permission change during "make install" on Ubuntu only of course.

Just another idea in the hope of improving the end-user experience.