Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp348566ybt; Mon, 6 Jul 2020 10:45:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz2TxQ2HJq4KgiP+pXz3XCgfkbpz4dmo6Tjht3KvZ0HwqJpxE26ewW6854Aoh5YM9i6anQy X-Received: by 2002:aa7:ca05:: with SMTP id y5mr30510775eds.204.1594057558447; Mon, 06 Jul 2020 10:45:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594057558; cv=none; d=google.com; s=arc-20160816; b=tt1bE1dRhYow5EZwtTN1q0HdlGQoKdIgxEq2WJhDjWVSnaPUtwg9bXY8wfLz7rWaxi MKhqyF2sTa+uwnpIeBJOuFng711lE0myw4TJ+uVPOn4gP/TLiaJ5sEO8MRxgKq2urNDe isQ100nd0ca8DxBTHVHdi0YLYXdRNVxqgVMewZVmRsc+MHZO5DG0ZHBO0+dwm15B1qAo QQI1HA0alXWS/9bZylAZywt5nzOidWq6HCgR70rY/7XjS4GIRN5g/LYVutmdOMhjJYFi T5ablqLMXOPRLZc4K9dTKXP95LK63432BSgbkipmRgHU5GlirR+a0tmJZwpr9+R3J+G9 dm8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=L3Yncxwg7P5JoBewxN5JQLTf6HCT9/+bIRyo76/+FAI=; b=D9fIcsUUW7rCHNZ6rQTQohsHhC5dyDxP6ZAO8TQQgC6Hj1KI36LPbosp71YrDfqlk7 EdC/0kGVj4OHtKb4Ahkmt/Xc58qvAv7eJrSzE4Q31MBceV6RGq0CmbpN/SVIh6YqCz/3 xRxN3D48FNM4vmEqff9m/Px7zTx6HJwuT5Vg4pwDjXa1IjAts3ljK784jcz091KV8PQ4 nykL+OrKQQeID7KwotFrwwdIJAz6jCqEd7cNVPUw0w1PUTZnSAZPbUVgW3Qyugoms3JQ 3CuTQGeEKB4oDCAaNwvT6TlPXVOmvj9TFonEy19fUOpyLyC67XRSIUwwVaBvb/GToXTg YzYw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p14si13710530ejr.470.2020.07.06.10.45.35; Mon, 06 Jul 2020 10:45:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729740AbgGFRpJ (ORCPT + 99 others); Mon, 6 Jul 2020 13:45:09 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:36578 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729550AbgGFRpI (ORCPT ); Mon, 6 Jul 2020 13:45:08 -0400 Received: from ip5f5af08c.dynamic.kabel-deutschland.de ([95.90.240.140] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jsVAU-0007so-Be; Mon, 06 Jul 2020 17:44:38 +0000 Date: Mon, 6 Jul 2020 19:44:37 +0200 From: Christian Brauner To: Nicolas Viennot Cc: Paul Moore , "Serge E. Hallyn" , Adrian Reber , Eric Biederman , Pavel Emelyanov , Oleg Nesterov , Dmitry Safonov <0x7f454c46@gmail.com>, Andrei Vagin , =?utf-8?B?TWljaGHFgiBDxYJhcGnFhHNraQ==?= , Kamil Yurtsever , Dirk Petersen , Christine Flood , Casey Schaufler , Mike Rapoport , Radostin Stoyanov , Cyrill Gorcunov , Stephen Smalley , Sargun Dhillon , Arnd Bergmann , "linux-security-module@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "selinux@vger.kernel.org" , Eric Paris , Jann Horn , "linux-fsdevel@vger.kernel.org" Subject: Re: [PATCH v4 3/3] prctl: Allow ptrace capable processes to change /proc/self/exe Message-ID: <20200706174437.zpshxlul7rl3vmmq@wittgenstein> References: <20200701064906.323185-1-areber@redhat.com> <20200701064906.323185-4-areber@redhat.com> <20200702211647.GB3283@mail.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 06, 2020 at 05:13:35PM +0000, Nicolas Viennot wrote: > > > This is scary. But I believe it is safe. > > > > > > Reviewed-by: Serge Hallyn > > > > > > I am a bit curious about the implications of the selinux patch. > > > IIUC you are using the permission of the tracing process to execute > > > the file without transition, so this is a way to work around the > > > policy which might prevent the tracee from doing so. > > > Given that SELinux wants to be MAC, I'm not *quite* sure that's > > > considered kosher. You also are skipping the PROCESS__PTRACE to > > > SECCLASS_PROCESS check which selinux_bprm_set_creds does later on. > > > Again I'm just not quite sure what's considered normal there these > > > days. > > > > > > Paul, do you have input there? > > > > I agree, the SELinux hook looks wrong. Building on what Christian said, this looks more like a ptrace operation than an exec operation. > > Serge, Paul, Christian, > > I made a PoC to demonstrate the change of /proc/self/exe without CAP_SYS_ADMIN using only ptrace and execve. > You may find it here: https://github.com/nviennot/run_as_exe > > What do you recommend to relax the security checks in the kernel when it comes to changing the exe link? Looks fun! Yeah, so that this is possible is known afaict. But you're not really circumventing the kernel check but are mucking with the EFL by changing the auxv, right? Originally, you needed to be userns root, i.e. only uid 0 could change the /proc/self/exe link (cf. [1]). This was changed to ns_capable(CAP_SYS_ADMIN) in [2]. The original reasoning in [1] is interesting as it basically already points to your poc: "Still note that updating exe-file link now doesn't require sys-resource capability anymore, after all there is no much profit in preventing setup own file link (there are a number of ways to execute own code -- ptrace, ld-preload, so that the only reliable way to find which exactly code is executed is to inspect running program memory). Still we require the caller to be at least user-namespace root user." There were arguments being made that /proc//exe needs to be sm that userspace can have a decent amount of trust in but I believe that that's not a great argument. But let me dig a little into the original discussion and see what the thread-model was. At this point I'm starting to believe that it was people being cautios but better be sure. [1]: f606b77f1a9e ("prctl: PR_SET_MM -- introduce PR_SET_MM_MAP operation") [2]: 4d28df6152aa ("prctl: Allow local CAP_SYS_ADMIN changing exe_file") [3]: https://lore.kernel.org/patchwork/patch/697304/ Christian