From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932871AbcHKDjj (ORCPT ); Wed, 10 Aug 2016 23:39:39 -0400 Received: from mail-db5eur01on0139.outbound.protection.outlook.com ([104.47.2.139]:35739 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932407AbcHKDjh (ORCPT ); Wed, 10 Aug 2016 23:39:37 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=skinsbursky@virtuozzo.com; Reply-To: Subject: Re: [PATCH] prctl: remove one-shot limitation for changing exe link 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> To: "Eric W. Biederman" , Cyrill Gorcunov CC: , , , , , , , , , , , , , From: Stanislav Kinsburskiy Message-ID: <3647508c-aa94-8540-6fbc-f781aeea77ce@virtuozzo.com> Date: Wed, 10 Aug 2016 12:48:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <87y44j6nib.fsf@x220.int.ebiederm.org> Content-Type: text/plain; charset="windows-1251"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [178.19.210.162] X-ClientProxiedBy: AM5PR0901CA0012.eurprd09.prod.outlook.com (10.164.186.150) To HE1PR0802MB2457.eurprd08.prod.outlook.com (10.175.34.142) X-MS-Office365-Filtering-Correlation-Id: c8a5558c-ef35-4144-6bc5-08d3c10bd398 X-Microsoft-Exchange-Diagnostics: 1;HE1PR0802MB2457;2:WUL73oCchmtZaMJ0wxzDeKxBlRVUjAEyBuAh0al7u//kRPEatdbgjMw9Cockggg9v4g2xsYodRVWyPD1eqeZ+f0DAyuwED5zTRXTVprfAbZyQjM6hVU/GcgH51W6DrGKkddV+foM9BLQvqEW0pbAsdGfHRX8a9Qmg+ksAZdT1KSvCDQzXb7yZO8+58aClbcj;3:rLg0kXScFEnGJI3exs0DFg3pQWC4GWjiBSDWyzi8mPqwW83G64M2OYkDxP7lqsbMAR4FwiuwH3itlpeYQ71P+0Jg0NqdH/gV2o8xvS3dtzMun5pOCIMNsFa+BA1LxyyY X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0802MB2457; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0802MB2457;25:hTUlXln76cH2gAI99ttGCE8iZ5j/vYcX24CGEp7D+1SRr6hbRVfFYNRys5jK39GYMf48uSWdlqyzMUR8NcLJaqTe5E2ovOFv+BrKR9bmvbnsmzRmQJfRFFMeJMZfifofkaHiFEVagzfM/ih1xWLoUNjhfZTNjKdJSArnUKC8a356jPN98jfZXC0JkamINtRd+gIWKNzLcQW9c2b+0PBqWNOpYH5DZlmLtejYVzswpDi+hPcSx2/w1u4ZoTG1QMwZ6a4JPbTmrnobbfwSlYBg4DD9NUX2eyC5o/lHMlamGVbuQYT/DushVveImE05Fq6A/v+tSVVqY6Nv1GOcyGkzFKlSluyV/xfIlBq4B0HywJyU1em8NWYl1g3CIIGWK3VJdS4jiQdBjakLO0eVD33cU6j/ANRFtFSqoMNUOE80YVqFb6VngMpAY+0rFP50vVZXpZiUBKWNo0czMaOjKYrjFcYA3fcYzNXenzUcVAooIXyMjoK9hztfy2KKQZ+aZzEmJn7vwAO2gxfVVGtIDNgorJaDakAVM3aLlwnpBSN5J0Sa1JAzk/bM+J9g0tWFJvlFLf5XIX8xJEqF9n7Tg9ETGgaG9x5zy2QOr1Q1vIpbe9D0KuD4hl9TJMAjvCr/zLx5mFr8AAGDLLgBLU57F7s3LzgGVoNWMYGMQu8Ea71bevXWoK0uec4DQCPELjBzFK+8VDlbiHUd2WOPDKIEMFnGc8nfptrvoSHyIrINeyVMCG0= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0802MB2457;31:vNId/JSyXKBpSWGHtBpd5vW3nTTPBpq30U7mOsbilvMBuyG16pogEGzQaUTU7i0JVpvUl2R95gaJTOZGGpd0DrkyJmiB1MK4t+Q4Wfp8iTs111AufexpTaA1Et8eSr/hT7JZNva49b7cyjn1caH5IhPTv79TpQVQbLaYWnqFuklu/P6qABk+BE+aiItt94x6FK7UYYvigAbbYzUA1j5zrM2KgbR285KPwKATwJkVRf0=;4:3igJtZqHac8mOYyqieR7R63CzCIGksJT+ZUJjZNBeIEpLqvJnbo7Fm88PDEgx0V2IUO2hiQCnVFItUN097LgE8CGr6xhq7+qCD+9aYUYMfgl7IDFwwwvDF3ECWRHvZ2x2IFxQQYd43Z1TX+N1CKdDpU0DibWCZjyelZGb55jQlgW5B0nxEVtGeKm8JV6m5MN+Z8VaZSBv2SKWVS9SAlQYBRiUY2nLarLqbxew+k7ZAtTjDq/IWf5w/fx5mk/GmNUHjKVhMXyoYHSGt1wMXiMzL3aafOGfCOWw7Nr6ZYMKEBRhYydXDqtqDgIybToqQu0SgWHR86mhgk18gRSCw2R8qN5ShupnInpnLMI59/iMy41WkaBssvvK6OdUBKxGc9YEElX9rNIee1hkBWvoI1T29WC0/JutE7UvWdCApwjqjvF32ZIrSFBauOnqlvxkXZxCNKyD+qSS+mgHGSvnTP+SIqM/IMGKK++qn9Qk2nI8Vl2Qt47VrNzReLOlK9kuA/u X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(72170088055959); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046);SRVR:HE1PR0802MB2457;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0802MB2457; X-Forefront-PRVS: 0030839EEE X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(24454002)(189002)(199003)(7846002)(36756003)(8666005)(106356001)(2870700001)(23686003)(68736007)(19580405001)(31696002)(2906002)(105586002)(31686004)(16300500001)(42186005)(3450700001)(93886004)(7736002)(7416002)(50466002)(189998001)(83506001)(81166006)(81156014)(19580395003)(8676002)(4326007)(305945005)(76176999)(50986999)(54356999)(86362001)(107886002)(3846002)(33646002)(586003)(43066003)(6116002)(5001770100001)(2950100001)(4001350100001)(4001430100002)(66066001)(97736004)(47776003)(77096005)(64126003)(101416001)(53806999)(7059030);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR0802MB2457;H:[10.134.193.232];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?windows-1251?Q?1;HE1PR0802MB2457;23:C7kclW3Ryn/6cOexkM2RBh/WQwnnlqEGFc0?= =?windows-1251?Q?3jafG9m5VXd4pyg5Y/FKXFe3gTL4nP8krIm/V+suFPgHU6vphEvi5kUf?= =?windows-1251?Q?sNXWTKbG9158OlrZqkSQxt1ffcZJu9lpAiTYffNYzRxySYnKiEn12UzZ?= =?windows-1251?Q?uDCplZ5O9VSa7GZgw/bpsav7jIIK2xrflGAKe1ClHjBnvQWfDVVCgCMj?= =?windows-1251?Q?0DdSO1ZKhUXBZhN8kBxU2F6DykUg/Rqp6+mq2lvoKd4hX48M2ZmLWcWT?= =?windows-1251?Q?g51rl/fhsXq+yhQb4MBWk8zuJpLHMZHhMv8gbbQxpcLNk02tlP+MWyOp?= =?windows-1251?Q?uEOQodvwYKwu4JeRUCtEyQ1AZKQYGuUnGcmBEx3uKiidl7VBdICCgVAh?= =?windows-1251?Q?3CWq8qXlG2p9V0pM6hikEjzq7vN6VCfj5ib0bwfODEbewdqGn56Pl23a?= =?windows-1251?Q?A6shIcrE3gIOtmCHv+wyj7bDnuQu1k4fNcwr5n8MLf11mjDV+LYWCkxM?= =?windows-1251?Q?Ui4neNQNMjsRr6CSfS9LbzbV6QaS9XyHCrNhM69+dJ7qvakdNCiKljxG?= =?windows-1251?Q?tZNtCijCdexQ/0FC2MIbIgmYD0692vOa2I7PkE3F7CB0rhy1dC4eu3B2?= =?windows-1251?Q?WqItANKhIdN5fpOsAUANkufe15wKG6cdQ6wOIpE9JepRr+MUw5qOiPFk?= =?windows-1251?Q?bi9JFfHTNivXNSt9plMOui168FC8U3TR/Jf+cRf2tQUKTHXKazlZ143O?= =?windows-1251?Q?5sH4kPJsv9lX9Z2nUIzmjE1ZyVL3zfCvZuz04nJuJV0Hcl0NW6zZYYC8?= =?windows-1251?Q?cO5QJ8YHx1uX3eknUjTUnx8mLDW71Hfo7AkW4ep/LObG13anTF8O4ill?= =?windows-1251?Q?UiXCmpjhgQvN5IJv9xhBtD772ellqbfC622j68ZXuLMZ2ze2YZz2iKbe?= =?windows-1251?Q?MjxvT+5XQRXcT4MVfo5YLWZTWmDeNEqD4IkapGkDuR5ciAj/cEXfz9wo?= =?windows-1251?Q?G6JGofPISShb/XiX2XU98gg4d2Cu6yorJ881I5hVc8eDdHSuPSdwoeh/?= =?windows-1251?Q?SYl7zSDHtIQliZTREYap/vt2B1/J+kAhdh+xP7NtaPQdisXWJU0a+Wp4?= =?windows-1251?Q?w9IPPtZvze07T+Pw5pMYnVyCjgQeZRBiGNxacwmS+bfn+gmQRElGy7Ed?= =?windows-1251?Q?eslAGjp73nL3gIjO/W16Duur+1Fnxnah2l/CybXNevYtwagu5qufTmRb?= =?windows-1251?Q?ZKs8EAiembmwVKUiEe52dve0hdziGKVNQEPHtGPkV+ZYals0hu6gcAWt?= =?windows-1251?Q?KrD8LDIuWlA/cRBP6nG0PJDpLgzufW/gofEHa75CXIeBy48DfR/PtbNc?= =?windows-1251?Q?svxxBcMH/hhd6ANKrnIyI4O1xbgXeiNkNDbnzYXkrkt58qrTMFUYV2ho?= =?windows-1251?Q?dWWYPKsuXC6cyo7aMSnp8RBgaSql1rzsEdSSZC5DI0WIz1Yxni+CM31o?= =?windows-1251?Q?9C/F7wa8kYCV956qSi208WAuUPAZj?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0802MB2457;6:46/Q22QGAAUE0VxstXcFSEvvFNQuMWWl1TgxPDj5act4qvLQmGheYk2GUiudYPyzqvrt7bbwz/BM+uOJ3EKx5xy3wzhB4+avRPAKW7Myr10DG/98eDAr6oSoKCnmiy3U9XcKs5WlYMhTWq5lseorJbC9fVDolc+dKq3cBRfEUfh19pxSBTgkHAwileAaJSNwtnOOszLdcTx9F3rcdhiu7fINEY+Utcu03/byxoLz+kVz7z+uxunsh5Ndves9Ix5A2jDKGiGsOn/YqYtL22i8HE8PgWwcdk5GUjapF2fcOPJ01ZOkoUy5RM65S0H+qweQ;5:8sBYlALngwZEHfP00huVzTYWKIIt9Umt/xvMzGF5nN2bU0BFlmqQb6dX4w5IT7TEiPL0zIjglnR5gzpHOxIa3vQLBB5dpQG0JBmpbn1L8sjvrFi43MVXaFTE4/uFmxfs+q3DmiorZs9tizezgDXm8g==;24:vPHQ6yTJ4086wk3zNJEnH4q8YRYB8aexYa25HG8Yd//Uk6m2zK1PSyNMPfjMGljQVGKbhNQLhtXg6/gtz/JDfhNbA22YKhJVXuABIGtKZms=;7:uDUiXU4UsYS6iBRrBSnHdwFX5B6cTgCHqGMycb38Ok3ZiYOgHbXvy2oXSeMP/GFSrKQzPksLAhEUSotmGqqKKmUUzSECykj7ZWGwYitdrqYZ5N0j0D/iMA8vXFH+mg0sv/TfKfDXXokDjcGKYtdd8XbZqOF5uBjFTDqoz/L39R1AeZnp0aDanEdhVzZQnLnrWIpYHbXJcinclgfDnmjf4/3Qms7hO+RqKY2P9JSzComv/1fX2SoyqWyYeX3gbVdH SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;HE1PR0802MB2457;20:j5A2d0b2hZ1KBF8UZlrxuyJH7Mi0NrobWeIw2OitUanmpsjw+0TqNDuApL3XQMNLUuNX1rxcTuIypUitRZFpONUyzsAHlh+jf/3L5e5OZYxVev85XUBdpt0wnmudd2eXbQRXT+M0cimzUKV018shFRXP5N+jxNI8SOKgLzA2a4U=;23:tnHjiX2EEMPEJK0Cq2q5GzQ3SxystfiLYHjG/cVtATcJe9G2pQbpNUoZ6v7J9ZR+ueJq7h5tytoeTkodFAK1+OmjUbyqLFO8fTnMcjc2Akoc/d6fYVdIWir8xD2czRfk6uzLBYqgqlvElS8Zu3zaW22/A9k988vtzzrI4VAxt20VfpLiiuQsPbaYpRQLF7yx X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2016 10:48:11.7125 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2457 X-OriginatorOrg: virtuozzo.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 30.07.2016 19:31, Eric W. Biederman пишет: > 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. >>> >>> Effectively what we check the old mapping for and refuse to remove the old >>> mm_exe_file if it exists. >>> >>> I think a reasonable argument can be made that if the file is >>> executable, and it is mmaped with executable pages that exe_file is not >>> a complete lie. >> I might be missing something obvious, so sorry for the question -- >> when criu setups old exe link the inode we obtain from file open >> is not mapped into memory, the old exe not read by anyone because >> it's not even executed anyhow. So I don't really understand which >> mapping we should check here. Mind to point me? > That sounds like an out and out bug that should not be preserved. > Of course we should mmap the executable and set it up so that it can be > executed (at least as much as the executable was previously mapped). > Anything else is a buggy restart, and lying to userspace. > >>> Which is the important part. At the end of the day how much can >>> userspace trust /proc/pid/exe? If we are too lax it is just a random >>> file descriptor we can not trust at all. At which point there is >>> exactly no point in preserving it in checkpoint/restart, because nothing >>> will trust or look at it. >> You know, I think we should not trust exe link much, and in real we >> never could: this link is rather a hint pointing which executable a >> process has been using on execve call, once the process start working >> one can't be sure if the code currently running is exactly from the >> file pointed by exe link. It just a hint suitable for debuggin and >> obtain clean view of which processes are running on noncompromised >> system. Monitoring exe link change won't help much if there are >> malicious software running on the system. > But it is not just a hint. It is a record of which executable we called > execve on. Knowing which file was executed doesn't guarantee what is > running now but it provides a very strong hint. > > At then end of a restart the state of a process should be (by > definition) exactly the state the process was before a checkpoint > and thus a state the original executable could have gotten into. > > I admit it is possible for an application to unmap itself. I honestly > have not met that application (except perhaps criu). > >>> If the only user is checkpoint/restart perhaps it should be only ptrace >>> that can set this and not the process itself with a prctl. I don't >>> know. All I know is that we should work on making it a very trustable >>> value even though in some specific instances we can set it. >> Since as I said I suppose nobody except us using this feature, we can >> setup some sysctl trigger for it (I personally think this is an >> overkill, but OTOH if people rely on the exe link and not going >> to use criu at all, this trigger will help). > Some clarity of thought came to me, and I apologise for not replying > sooner with it sooner. > > My problem with the original patch submission is that it was > justifying changing prctl_set_mm_exe_file based on what > prctl_set_mm_exe_file does today. As prctl_set_mm_exe_file was added > for the checkpoint/restart case that is justifying changing code based > on a buggy implementation. > > It is necessary to look at the ordinary situation. Without > prctl_set_mm_exe /proc/[pid]/exe can be counted on as a record > of which executable was last passed to execve. Furthermore the state of > a process can be counted on to be a state reachable from calling > execve on /proc/[pid]/exe. > > Which means to preserve those expectations prctl_set_mm_exe_file should > in practice just be a nicer less cumbersome interface to things you can > already achieve with execve. > > Justifying removale of the one-short nature for prctl_set_mm_exe_file > is as straight forward as noting that a process can call execve on > any executable file. > > However when I compare the invariants that execve has on a file (such as > the executable being mmaped) I see some noticable disparities between > what prctl_set_mm_exe_file allows and what execve allows. With > prctl_set_mm_exe being less strict. > > So what I am requesting is very simple. That the checks in > prctl_set_mm_exe_file be tightened up to more closely approach what > execve requires. Thus preserving the value of the /proc/[pid]/exe for > the applications that want to use the exe link. Eric, could you elaborate on the checks, you mentioned? I don't see any significant checks, which are applicable to prctl_set_mm_exe_file. Say, there is a check for PF_NPROC_EXCEEDED in execve, but this is not applicable. Some of the checks are related to file open, but this is not done in prctl_set_mm_exe_file. There is some logic, related to "close on exec", but this is something which has to be avoided. Would be nice to have an example of a check, which is missing. > Once the checks in prctl_set_mm_exe_file are tightened up please feel > free to remove the one shot test. > > Eric