qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Vivier <laurent@vivier.eu>
To: Olivier Dion <olivier.dion@polymtl.ca>
Cc: qemu-devel@nongnu.org, john.ogness@linutronix.de
Subject: Re: [Qemu-devel] [PATCH 1/1] linux-user: Handle /proc/self/exe in syscall execve
Date: Mon, 2 Sep 2019 21:02:55 +0200	[thread overview]
Message-ID: <d1765c14-6abe-69b5-b4db-7a5dd13cf996@vivier.eu> (raw)
In-Reply-To: <875zmaeh1j.fsf@polymtl.ca>

Le 02/09/2019 à 19:36, Olivier Dion a écrit :
> 
> On 2019-08-23T12:58:43-0400, Laurent Vivier <laurent@vivier.eu> wrote:
> 
>> Le 07/08/2019 à 15:54, dion@linutronix.de a écrit :
>>> From: Olivier Dion <dion@linutronix.de>
>>>
>>> If not handled, QEMU will execve itself instead of the emulated
>>> process.  This could result in potential security risk.
>>>
> 
>> Could you explain what you mean by potential security risk?
> 
> I don't have any exploit in mind, but someone motivated enough could
> certainly find one.  For example, it's possible to ask qemu static to
> execute another program.

In the actual state, executing /proc/self/exe executes QEMU instead of
the binary and this is a minor bug not a security risk.

> The main point is that an emulator should never leak informations to its
> environnement.  If the emulated program can determine that it is being
> emulated, other than by an "official" way, then the emulator is at
> fault.

It should never leak _crucial_ information (like the serial number of
the host), but all emulators/hypervisors leak information (try to run
lscpu/lspci in a VM). In this case, again, I don't see any security risk.

Moreover qemu-user doesn't have kernel part and it has no way to elevate
privilege by itself (BTW you must not run it with suid bit).

We don't have a nice solution for all the files below /proc: we rely on
the path name and can't check if it's in a procfs filesystem, and that
is not perfect. Moreover, it doesn't work well if we use a link to
access the file or a relative path. If we want a solution managing all
the cases if becomes relatively complex.

From my point of view, all patches are welcome.

For this one:

- don't introduce it as security fix but as a bug fix
- propose a test case and show your fix really fixes it
- you should use do_openat() with execveat() as the exec_path can be
unset in the case of binfmt-misc with the credential flag (search for
AT_EXECFD in QEMU code).

Thanks,
Laurent


  reply	other threads:[~2019-09-02 19:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-07 13:54 [Qemu-devel] [PATCH 0/1] Handle /proc/self/exe in execve dion
2019-08-07 13:54 ` [Qemu-devel] [PATCH 1/1] linux-user: Handle /proc/self/exe in syscall execve dion
2019-08-23 16:58   ` Laurent Vivier
2019-09-02 17:36     ` Olivier Dion
2019-09-02 19:02       ` Laurent Vivier [this message]
2019-09-16 15:55 ` [Qemu-devel] [PATCH v2 0/1] Handle /proc/self/exe in execve Olivier Dion
2019-09-16 15:55   ` [Qemu-devel] [PATCH v2 1/1] Handle /proc/self/exe in syscall execve Olivier Dion
2019-09-16 16:55   ` [Qemu-devel] [PATCH v2 0/1] Handle /proc/self/exe in execve no-reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d1765c14-6abe-69b5-b4db-7a5dd13cf996@vivier.eu \
    --to=laurent@vivier.eu \
    --cc=john.ogness@linutronix.de \
    --cc=olivier.dion@polymtl.ca \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).