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
next prev parent 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).