[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/1] linux-user: Handle /proc/self/exe in syscal
From: |
Laurent Vivier |
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 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 |
Le 02/09/2019 à 19:36, Olivier Dion a écrit :
>
> On 2019-08-23T12:58:43-0400, Laurent Vivier <address@hidden> wrote:
>
>> Le 07/08/2019 à 15:54, address@hidden a écrit :
>>> From: Olivier Dion <address@hidden>
>>>
>>> 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