From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QhK3J-0001f6-QE for qemu-devel@nongnu.org; Thu, 14 Jul 2011 07:26:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QhK3F-0005QJ-4k for qemu-devel@nongnu.org; Thu, 14 Jul 2011 07:25:57 -0400 Received: from adelie.canonical.com ([91.189.90.139]:52631) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QhK3E-0005QF-QX for qemu-devel@nongnu.org; Thu, 14 Jul 2011 07:25:53 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by adelie.canonical.com with esmtp (Exim 4.71 #1 (Debian)) id 1QhK3C-0005Iq-TY for ; Thu, 14 Jul 2011 11:25:51 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id EB7DD2E8954 for ; Thu, 14 Jul 2011 11:25:49 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2011 11:19:44 -0000 From: Stefan Hajnoczi <807893@bugs.launchpad.net> Sender: bounces@canonical.com References: <20110709081416.14384.20718.malonedeb@wampee.canonical.com> <20110714103722.31228.34205.malone@soybean.canonical.com> Message-Id: Errors-To: bounces@canonical.com Subject: Re: [Qemu-devel] [Bug 807893] Re: qemu privilege escalation Reply-To: Bug 807893 <807893@bugs.launchpad.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Thu, Jul 14, 2011 at 11:37 AM, Andrew Griffiths <807893@bugs.launchpad.net> wrote: > Regarding the threads having different privilege level, I have isolated > that to being related to my grsecurity configuration (more specifically, > chroot_findtask will block it). > > While it's still an issue on older glibc where the setuid/setgid code > does not enforce it across all threads, it may not be high priority > since fixing it would be a lot more effort. Wow, just learnt something new that glibc does behind our backs :). I see it uses SIGRTMIN+1 to signal threads and get them to do the set*id system calls. I'm glad it does this because although most QEMU threads should be started after command-line parsing, I can think of instances where we might start a thread before -runas is completed. Stefan -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/807893 Title: qemu privilege escalation Status in QEMU: Confirmed Bug description: If qemu is started as root, with -runas, the extra groups is not dropped correctly /proc/`pidof qemu`/status .. Uid: 100 100 100 100 Gid: 100 100 100 100 FDSize: 32 Groups: 0 1 2 3 4 6 10 11 26 27 = ... The fix is to add initgroups() or setgroups(1, [gid]) where appropriate to os-posix.c. The extra gid's allow read or write access to other files (such as /dev etc). Emulating the qemu code: # python ... >>> import os >>> os.setgid(100) >>> os.setuid(100) >>> os.execve("/bin/sh", [ "/bin/sh" ], os.environ) sh-4.1$ xxd /dev/sda | head -n2 0000000: eb48 9000 0000 0000 0000 0000 0000 0000 .H.............. 0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ sh-4.1$ ls -l /dev/sda brw-rw---- 1 root disk 8, 0 Jul 8 11:54 /dev/sda sh-4.1$ id uid=3D100(qemu00) gid=3D100(users) groups=3D100(users),0(root),1(bin),2(d= aemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/807893/+subscriptions