Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF826C433EF for ; Tue, 21 Dec 2021 17:36:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240444AbhLURgI (ORCPT ); Tue, 21 Dec 2021 12:36:08 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:40538 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240435AbhLURgH (ORCPT ); Tue, 21 Dec 2021 12:36:07 -0500 Received: from in02.mta.xmission.com ([166.70.13.52]:44578) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mzj3V-009677-7v; Tue, 21 Dec 2021 10:36:05 -0700 Received: from ip68-227-161-49.om.om.cox.net ([68.227.161.49]:54094 helo=email.froward.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mzj3U-0048xo-5Q; Tue, 21 Dec 2021 10:36:04 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Waiman Long Cc: Alexander Viro , Kees Cook , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Laurent Vivier , YunQiang Su , Helge Deller , Willy Tarreau , Linus Torvalds References: <20211221021744.864115-1-longman@redhat.com> <87lf0e7y0k.fsf@email.froward.int.ebiederm.org> <4f67dc4c-7038-7dde-cad9-4feeaa6bc71b@redhat.com> Date: Tue, 21 Dec 2021 11:35:57 -0600 In-Reply-To: <4f67dc4c-7038-7dde-cad9-4feeaa6bc71b@redhat.com> (Waiman Long's message of "Tue, 21 Dec 2021 11:41:27 -0500") Message-ID: <87czlp7tdu.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1mzj3U-0048xo-5Q;;;mid=<87czlp7tdu.fsf@email.froward.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.161.49;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX180lGSi0e9hseN5KMysEPq9tcqjvvxHmw4= X-SA-Exim-Connect-IP: 68.227.161.49 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH] exec: Make suid_dumpable apply to SUID/SGID binaries irrespective of invoking users X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Adding a couple of other people who have expressed opinions on how to mitigate this issue in the kernel. Waiman Long writes: > On 12/21/21 10:55, Eric W. Biederman wrote: >> Waiman Long writes: >> >>> The begin_new_exec() function checks for SUID or SGID binaries by >>> comparing effective uid and gid against real uid and gid and using >>> the suid_dumpable sysctl parameter setting only if either one of them >>> differs. >>> >>> In the special case that the uid and/or gid of the SUID/SGID binaries >>> matches the id's of the user invoking it, the suid_dumpable is not >>> used and SUID_DUMP_USER will be used instead. The documentation for the >>> suid_dumpable sysctl parameter does not include that exception and so >>> this will be an undocumented behavior. >>> >>> Eliminate this undocumented behavior by adding a flag in the linux_binprm >>> structure to designate a SUID/SGID binary and use it for determining >>> if the suid_dumpable setting should be applied or not. >> I see that you are making the code match the documentation. >> What harm/problems does this mismatch cause in practice? >> What is the motivation for this change? >> >> I am trying to see the motivation but all I can see is that >> in the case where suid and sgid do nothing in practice the code >> does not change dumpable. The point of dumpable is to refuse to >> core dump when it is not safe. In this case since nothing happened >> in practice it is safe. >> >> So how does this matter in practice. If there isn't a good >> motivation my feel is that it is the documentation that needs to be >> updated rather than the code. >> >> There are a lot of warts to the suid/sgid handling during exec. This >> just doesn't look like one of them > > This patch is a minor mitigation in response to the security > vulnerability as posted in > https://www.openwall.com/lists/oss-security/2021/10/20/2 (aka > CVE-2021-3864). In particular, the Su PoC (tested on CentOS 7) showing > that the su invokes /usr/sbin/unix_chkpwd which is also a SUID > binary. The initial su invocation won't generate a core dump because > the real uid and euid differs, but the second unix_chkpwd invocation > will. This patch eliminates this hole by making sure that all SUID > binaries follow suid_dumpable setting. All that is required to take advantage of this vulnerability is for an suid program to exec something that will coredump. That exec resets the dumpability. While the example exploit is execing a suid program it is not required that the exec'd program be suid. This makes your proposed change is not a particularly effective mitigation. The best idea I have seen to mitigate this from the kernel side is: 1) set RLIMIT_CORE to 0 during an suid exec 2) update do_coredump to honor an rlimit of 0 for pipes Anecdotally this should not effect the common systems that pipe coredumps into programs as those programs are reported to honor RLIMIT_CORE of 0. This needs to be verified. If those programs do honor RLIMIT_CORE of 0 we won't have any user visible changes if they never see coredumps from a program with a RLIMIT_CORE of 0. I have been meaning to audit userspace and see if the common coredump catchers truly honor an RLIMIT_CORE of 0. Unfortunately I have not found time to do that yet. Eric