From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752191AbcGaWuI (ORCPT ); Sun, 31 Jul 2016 18:50:08 -0400 Received: from mail-vk0-f50.google.com ([209.85.213.50]:33690 "EHLO mail-vk0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750978AbcGaWuE (ORCPT ); Sun, 31 Jul 2016 18:50:04 -0400 MIME-Version: 1.0 In-Reply-To: <20160731224352.GJ26208@uranus> References: <20160712152940.24895.61315.stgit@localhost.localdomain> <8a863273-c571-63d6-c0c3-637dff5645a3@virtuozzo.com> <87y44pbmtc.fsf@x220.int.ebiederm.org> <20160725192242.GA26208@uranus> <87a8h58pac.fsf@x220.int.ebiederm.org> <20160726083445.GB26208@uranus> <87y44j6nib.fsf@x220.int.ebiederm.org> <20160731224352.GJ26208@uranus> From: Andy Lutomirski Date: Sun, 31 Jul 2016 15:49:42 -0700 Message-ID: Subject: Re: [PATCH] prctl: remove one-shot limitation for changing exe link To: Cyrill Gorcunov Cc: "Eric W. Biederman" , Stanislav Kinsburskiy , Peter Zijlstra , Ingo Molnar , Michal Hocko , Kees Cook , "linux-kernel@vger.kernel.org" , Mateusz Guzik , Benjamin Segall , John Stultz , Oleg Nesterov , matthltc@us.ibm.com, Andrew Morton , Vlastimil Babka , xemul@virtuozzo.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 31, 2016 at 3:43 PM, Cyrill Gorcunov wrote: > On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote: >> Cyrill Gorcunov writes: >> >> > On Mon, Jul 25, 2016 at 02:56:43PM -0500, Eric W. Biederman wrote: >> > ... >> >> >> >> >> >> Also there is a big fat bug in prctl_set_mm_exe_file. It doesn't >> >> >> validate that the new file is a actually mmaped executable. We would >> >> >> definitely need that to be fixed before even considering removing the >> >> >> limit. >> >> > >> >> > Could you please elaborate? We check for inode being executable, >> >> > what else needed? >> >> >> >> That the inode is mmaped into the process with executable mappings. > > Eric, thanks for clarification. Let me talk from CRIU perspective (because > the interface came from its need) -- the former executable may no longer > exist, completely: for such cases in CRIU we simply create that named > "ghost" files wich are just literally removed upon open. So we simply > can't mmap the former executable into memory. > > Moreover I would really _like_ to not do this check -- the former > intarface has been done exactly to behave as it does now: don't > read original file into memory (in criu, when we setup this exelink, > the original memory of a process already restored so additional > mmap for every executable is purely waste of time). Eric, I think I generally disagree with you here. I see no compelling reason that we shouldn't allow unlimited changes to exe_file so long as the selected files are executable. (It might make sense to check that LSM is okay, but even that is a dubious requirement, I think.) What kind of attack are you worried about? That being said, we should probably make it so that audit logs indicate the real executable that was execve'd, but I'd imagine that this is already the case. But I don't think the original executable needs to be directly visible in /proc. --Andy