Re: [Qemu-devel] [PATCH] qga: set umask 0077 when daemonizing (CVE-2013-2007)

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]

On 05/07/2013 02:28 PM, mdroth wrote:
>>
>> This points out that:
>>
>> 1. the documentation for guest-file-open is insufficient to describe our
>> limitations (for example, although C11 requires support for the "wx"
>> flag, this patch forbids that flag)
> 
> Got a pointer? I can fix up the docs if need be, but fopen() docs that
> qemu-ga points at seem to indicate 0666 will be used for new files.
> That's no longer the case?

C99 and C11 don't care about permission bits of files created by fopen()
- that's a concept added by POSIX.  POSIX says that fopen() creates new
files with respect to the current umask settings (in other words, 0666
minus bits that umask forbids).  But since we weren't forbidding any
bits, that meant we were getting 0666 files.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html

This patch intentionally leaves things unchanged so that any file
created via guest-file-open still has mode 0666, just as it was
pre-patch (it's just that the mode bits are now set via fchmod instead
of implied via a umask of 0).

But pre-patch, we handed any string on to fopen (whether bogus, such as
"read", or valid C11, such as "wx", or even glibc extension, such as
"we") and whether it succeeded or failed was dependent on the extensions
supported in the version of libc running the guest agent.  Now
post-patch, we only accept a finite set of mode strings (those
documented in C99) and explicitly reject others, even if they used to
succeed.

The documentation in qga/qapi-schema.json doesn't mention anything about
the permissions given to created files (other than what you can infer by
chasing down the POSIX rather than the C99 definition of fopen), and it
only says that @mode is as per fopen() without saying whether it is C99
or C11 fopen().

> 
>>
>> 2. guest-file-open is rather puny; we may need a newer interface that
>> allows the user finer-grained control over the actual mode bits set on
> 
> Yes, shame it wasn't there at the start. a guest-file-open-full or
> something with support for specifying creation mode will have to do it.

It boils down to fopen() mode argument being puny when compared to
open()'s bit flags and optional mode_t argument.  We inherently limited
ourselves by designing after the higher-level C interface instead of the
lower-level POSIX interface.  So yes, hopefully when we design a new
more powerful qga command, we will put more thought into designing it to
do everything that we really want.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]