[libvirt] using virSetUIDGID() with unprivileged qemu defeats setuid helper

[Daniel P. Berrange]

On Mon, Mar 11, 2013 at 01:21:48PM -0600, Eric Blake wrote:
> On 03/10/2013 10:25 PM, Csaba Henk wrote:
> > Hi,
> > 
> > I recently experienced that my qemu guest (which I'm using with
> > unprivileged user) fails to start with:
> > 
> >     error: internal error process exited while connecting to monitor: chardev: opening backend "pty" failed
> > 
> > This happens upon trying to facilitate the
> > 
> >     <serial type='pty'>
> >       <target port='0'/>
> >     </serial>
> >     <console type='pty'>
> >       <target type='serial' port='0'/>
> >     </console>
> > 
> > stanzas, for which qemu wants to grab a pty through openpty(3).
> > openpty needs to have the assigned pty to be chown'd to the qemu
> > user, which is attempted via running the setuid helper program
> > pt_chown. However, chown(2) fails with EPERM.
> 
> Thanks for the analysis.
> 
> > 
> > The culprit seems to be the commits
> > 
> >     v1.0.3-rc1~113: util: virSetUIDGIDWithCaps - change uid while keeping caps
> >     v1.0.3-rc1~112: util: maintain caps when running command with uid != 0
> > 
> > which change how capabilities are manipulated before program execution.
> > 
> > Just immediately before the execve(2) call, the qemu process used to have
> > the following capabilities:
> > 
> >     CapInh:	0000000000000000
> >     CapPrm:	0000000000000000
> >     CapEff:	0000000000000000
> >     CapBnd:	ffffffffffffffff
> > 
> > since said commits, it looks like:
> > 
> >     CapInh:	0000000000000000
> >     CapPrm:	0000000000000000
> >     CapEff:	0000000000000000
> >     CapBnd:	ffffffe000000000
> 
> We are intentionally dropping capability bits; however, your report
> means we need to think twice about dropping CAP_CHOWN when there is a
> pty in play.
> 
> > 
> > as far as my capability-noob eyes can see, the bounding set lacks CAP_CHOWN
> > and thus pt_chown won't attain CAP_CHOWN despite running on uid 0, and the
> > EPERM is triggered.
> > 
> > How could we fix it? Qemu invocation should be customized or virExec() adjusted?
> > Or is there some configuration workaround?
> 
> Ideally, we would fix libvirt to open the pty and then hand the fd to
> qemu via SCM_RIGHTS, rather than letting qemu have to keep CAP_CHOWN.
> That way, qemu will never need to spawn the helper pt_chown app, and the
> lack of the capability would not be an issue.  But if that doesn't work
> out, then the fact that we can hot-plug a console means that we cannot
> know, at qemu start time, whether a later operation would hotplug a pty,
> so we may be forced to leave CAP_CHWON in the bounding set of all qemu
> processes.

'pt_chown' is a setuid helper program that GLibc can used to chown a PTY
to the current user. It is however obsolete and no correctly configured
Linux distro should require it anymore, since the dynamic devpts filesystem
will provide a PTY that already has the correct ownership. As such it is
correct that libvirt is blocking execution of pt_chown.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|