Le 02/09/2019 à 19:36, Olivier Dion a écrit : > > On 2019-08-23T12:58:43-0400, Laurent Vivier <laur...@vivier.eu> wrote: > >> Le 07/08/2019 à 15:54, d...@linutronix.de a écrit : >>> From: Olivier Dion <d...@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
