Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2378296pxb; Tue, 12 Oct 2021 05:29:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxR5NJPHdwgCQcUpcKu8eh8J5l5tWD9v4aLbV2AO5NONGqmlaF8DSR7I8NW2Y525oUcNIkL X-Received: by 2002:a05:6402:1b8a:: with SMTP id cc10mr49509816edb.313.1634041762868; Tue, 12 Oct 2021 05:29:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634041762; cv=none; d=google.com; s=arc-20160816; b=rphhdsPwtBCeH5n6yJD5lTJMgTMmN9KRZQH9y/fb+8m0VFBg6mgthuaZADF+2dopAy X/4vPvNVEM84F3Nxg8AwkemxLX1EdI7KoSzaLwNBaErCekdqSTQ1ozunEpZKSp33zQPz N4cnBHNyq6Atk3v/n+aNRelFiKjC1xRpb70djE3UcjrEKuTTdn/0PQYpghvtvZVCGGIJ tWm0KW1kzv2fFjgidBCaKZvE8FwzBjC+qXis0zhxQGzRNFUo5/fj6DK/19xn2uDEG9l0 zawecnEndhX86Nww+F8sxc19nna4C9uTy3v5BJfGm7tzmZ2WfUlIKRci621g2N/LmU7r KxxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=konfceEb5bDnI67wC9RxoqNAwxhbwwv9bAwx6wDgB/s=; b=rdElGHN/5r1TPe24IwLu7sy9yKJ/hh8zA1Jywk+q+lm3CIPS+xgurpsdfRRtBB8D7j TiZd5pEYqKNC3cYI+3YmxlEMoljvLFI0TUQmRGSjOwcBGNqi8XcQsps97/IaGmS6+rqz f6ceVpUuhyYCRYIeO324PaI/y3BjovIJ8BHK8jC0qSjJJL306hmKXJ+D4SBE9Yfgi92G jrowXNKU19KJ9aXRmhIhih/9yyLt5Mg26ZeYGErBst8xSlmsJ9I8xThLGA2memKVKm9m c7LLQ/dPQVTmFETMcGCaYKC2X5PzG1ibazmuuAaZzgyUju7bMvBVeNI12Wyd7M45OESZ p/uA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=NmenMucl; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w18si15134249edu.157.2021.10.12.05.28.57; Tue, 12 Oct 2021 05:29:22 -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; dkim=pass header.i=@gmail.com header.s=20210112 header.b=NmenMucl; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236420AbhJLM0s (ORCPT + 99 others); Tue, 12 Oct 2021 08:26:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236281AbhJLM0r (ORCPT ); Tue, 12 Oct 2021 08:26:47 -0400 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8B02C061570; Tue, 12 Oct 2021 05:24:45 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id y26so87783054lfa.11; Tue, 12 Oct 2021 05:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=konfceEb5bDnI67wC9RxoqNAwxhbwwv9bAwx6wDgB/s=; b=NmenMuclbaSVdFe0E0GhU2pmqEAc2Iq30zsbte/jdZxTo7nIJWiwZpbT/53oPLs+Qt +pn3zaO9BC6vp1wXRW4WrZ03ZDh88g+7p8KFbchHxblVx0ENoDG85rkJQIFMpZaN0PhK Tcpk6Iem+SVxlV1NTnn91ErVJfX4sjoT6askNCf8QFZC9LugLOrWDaJTc65UP/4OeDlg yjCINJUjYQkgnbkNgSXBBmljp+Gl2ZukNIWljw4rJUSdaRUvDzbA62jj6IRuxP6JeiqY C8Mg8U5K/oTA6kWN4Tm9hn0+KLTjsUTF7XUGcsbn6ljcHrl2T9UiBM3ZwMOfuile/tz+ vE2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=konfceEb5bDnI67wC9RxoqNAwxhbwwv9bAwx6wDgB/s=; b=ErPh+/YmmbvUm+CMy7neZ1mQey4bnJaKxK+8iWZ//5U8J4nmyG2Fd3ZxQyFKovklWc P7Mrbix4cEw9kFGoFi6jDETmfW4qNH0lq8fm3ckXhP1tkqSBAAXxmyVDjktbp/OCO9Ye sVfiNUfzPnKlDYQf9HKqO3ikY9N90Tk6M/0ZvYYg1fDv1F6sFndsV4DW3xxWZpwng6b4 DN5itSc0rQKbDtGavHxpS9aWvido5mbt9RGm07hLcLzLa/jeJRXOi+o9GrQku2rtWP5M f5WiGVhGVq9+iyyt98FPKYcWcPqPb/VDPXCj/3psSXOwYAnyHw5hgiSmQNqG9kbGf6gB oENg== X-Gm-Message-State: AOAM5339+VS19fOZysvrf2uGNW/cg054H+bGeCYdn/sGbbNf6a30uIcq 2slJMH8mtAQkyE6jJ+qrP/uZiMHxw0oBGb7DI6A= X-Received: by 2002:a05:651c:1304:: with SMTP id u4mr27924099lja.136.1634041484041; Tue, 12 Oct 2021 05:24:44 -0700 (PDT) MIME-Version: 1.0 References: <20211007004629.1113572-1-tkjos@google.com> <20211007004629.1113572-4-tkjos@google.com> In-Reply-To: From: Stephen Smalley Date: Tue, 12 Oct 2021 08:24:33 -0400 Message-ID: Subject: Re: [PATCH v4 3/3] binder: use euid from cred instead of using task To: Todd Kjos Cc: Paul Moore , Casey Schaufler , Greg Kroah-Hartman , arve@android.com, tkjos@android.com, maco@android.com, christian@brauner.io, James Morris , Serge Hallyn , Eric Paris , Kees Cook , Jann Horn , Jeffrey Vander Stoep , Mimi Zohar , LSM List , SElinux list , devel@driverdev.osuosl.org, linux-kernel , "Joel Fernandes (Google)" , "Cc: Android Kernel" , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 11, 2021 at 7:39 PM Todd Kjos wrote: > > On Mon, Oct 11, 2021 at 2:39 PM Paul Moore wrote: > > > > On Fri, Oct 8, 2021 at 5:24 PM Todd Kjos wrote: > > > > > > On Fri, Oct 8, 2021 at 2:12 PM Paul Moore wrote: > > > > > > > > On Wed, Oct 6, 2021 at 8:46 PM Todd Kjos wrote: > > > > > > > > > > Set a transaction's sender_euid from the 'struct cred' > > > > > saved at binder_open() instead of looking up the euid > > > > > from the binder proc's 'struct task'. This ensures > > > > > the euid is associated with the security context that > > > > > of the task that opened binder. > > > > > > > > > > Fixes: 457b9a6f09f0 ("Staging: android: add binder driver") > > > > > Signed-off-by: Todd Kjos > > > > > Suggested-by: Stephen Smalley > > > > > Cc: stable@vger.kernel.org # 4.4+ > > > > > --- > > > > > v3: added this patch to series > > > > > > > > > > drivers/android/binder.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > This is an interesting ordering of the patches. Unless I'm missing > > > > something I would have expected patch 3/3 to come first, followed by > > > > 2/3, with patch 1/3 at the end; basically the reverse of what was > > > > posted here. > > > > > > 2/3 and 3/3 both depend on 1/3 (add "cred" member of struct > > > binder_proc). I kept that in 1/3 to keep that patch the same as what > > > had already been reviewed. I didn't think much about the ordering > > > between 2/3 and 3/3 -- but I agree that it would have been sensible to > > > reverse their order. > > > > > > > > > > > My reading of the previous thread was that Casey has made his peace > > > > with these changes so unless anyone has any objections I'll plan on > > > > merging 2/3 and 3/3 into selinux/stable-5.15 and merging 1/3 into > > > > selinux/next. > > > > > > Thanks Paul. I'm not familiar with the branch structure, but you need > > > 1/3 in selinux/stable-5.15 to resolve the dependency on proc->cred. > > > > Yep, thanks. My eyes kinda skipped over that part when looking at the > > patchset but that would have fallen out as soon as I merged them. > > > > Unfortunately that pretty much defeats the purpose of splitting this > > into three patches. While I suppose one could backport patches 2/3 > > and 3/3 individually, both of them have a very small footprint > > especially considering their patch 1/3 dependency. At the very least > > it looks like patch 2/3 needs to be respun to address the > > !CONFIG_SECURITY case and seeing the split patches now I think the > > smart thing is to just combine them into a single patch. I apologize > > for the bad recommendation earlier, I should have followed that thread > > a bit closer after the discussion with Casey and Stephen. > > I'm happy to submit a single patch for all of this. Another part of > the rationale > for splitting it into 3 patches was correctly identify the patch that introduced > the patch that introduced the issue -- so each of the 3 had a different > "Fixes:" tag. Should I cite the oldest (binder introduction) with the "Fixes" > tag and perhaps mention the other two in the commit message? Couldn't you just split patch 1 into the "add cred to binder proc" part and "use cred in LSM/SELinux hooks" part, combine patch 3 with the "add cred to binder proc" part to create new patch 1, then "use cred in LSM/SELinux hooks" part is patch 2, and "switch task_getsecid to cred_getsecid" to patch 3? Then patch 1 can be cherry-picked/ported all the way back to the introduction of binder, patch 2 all the way back to the introduction of binder LSM/SELinux hooks, and patch 3 just back to where passing the secctx across binder was introduced.